Bump dependencies to support tasklists

[gjtorikian]

Re: #64 (comment)

Something is a bit missing when it comes to walking the nodes around a task list...it ends up in a recursion. Not sure if this is a problem here or upstream just yet.

[kivikakk]

oh good lord

[gjtorikian]

I continue to hate computers

[kivikakk]

[gjtorikian]

@kivikakk I believe something upstream is not quite right, but I haven't identified what it is just yet.

In this gem, parsing a file as

doc = CommonMarker.render_doc(text, :DEFAULT, %i[tasklist])
doc.to_html

works precisely as expected. to_html relies on the C lib's cmark_render_html function.

But when attempting to step through and render individual nodes:

CommonMarker::HtmlRenderer.new.render(doc)

the generation hangs.

That renderer depends on a node's type string to understand what to do. According to just puts node.type_string.to_s, this emits list, not an expected tasklist. Would you be able to help me sleuth this, or, if you're pressed for time, point out to me where I can go to look a bit further?

[kivikakk]

Ugh, I cannot believe what has happened here:

• commonmarker uses cmark_node_set_user_data and cmark_node_get_user_data to store a cache of the Ruby Node against the cmark node.
• the tasklist extension uses the same functions to store CMARK_TASKLIST_CHECKED and CMARK_TASKLIST_NOCHECKED, which are an enum.
• this means when storing CMARK_TASKLIST_NOCHECKED, the cached node is forgotten. (memory leak!)
• when storing CMARK_TASKLIST_CHECKED, we return it immediately as a VALUE in rb_node_to_value. The VALUE 1 is the Fixnum 0.
• in CommonMarker::Node#each, we get the first child and then repeatedly call next on it.
• Fixnum#next returns the next integer, i.e. it sits there looping through all integers starting at zero.

I don't have time to work on a fix for this atm, but hopefully this is enough of a pointer.

[kivikakk]

Relevant sections of code:

commonmarker/ext/commonmarker/commonmarker.c

Lines 83 to 101 in b9e5751

	static VALUE rb_node_to_value(cmark_node *node) {
	void *user_data;
	RUBY_DATA_FUNC free_func;
	VALUE val;
	if (node == NULL)
	return Qnil;
	user_data = cmark_node_get_user_data(node);
	if (user_data)
	return (VALUE)user_data;
	/* Only free tree roots. */
	free_func = cmark_node_parent(node) ? NULL : rb_free_c_struct;
	val = Data_Wrap_Struct(rb_mNode, rb_mark_c_struct, free_func, node);
	cmark_node_set_user_data(node, (void *)val);
	return val;
	}

commonmarker/lib/commonmarker/node.rb

Lines 55 to 65 in b9e5751

	# Public: Iterate over the children (if any) of the current pointer.
	def each(&block)
	return enum_for(:each) unless block_given?
	child = first_child
	while child
	nextchild = child.next
	yield child
	child = nextchild
	end
	end

[kivikakk]

And:

commonmarker/ext/commonmarker/tasklist.c

Lines 7 to 10 in 4da613e

	typedef enum {
	CMARK_TASKLIST_NOCHECKED,
	CMARK_TASKLIST_CHECKED,
	} cmark_tasklist_type;

commonmarker/ext/commonmarker/tasklist.c

Lines 65 to 71 in 4da613e

	long userdata;
	if (strstr((char*)input, "[x]")) {
	userdata = CMARK_TASKLIST_CHECKED;
	} else {
	userdata = CMARK_TASKLIST_NOCHECKED;
	}
	cmark_node_set_user_data(parent_container, (void*)userdata);

[kivikakk]

If possible, the tasklist code in cmark-gfm should use the node opaque area like the table extension does. (I haven't looked into this yet and didn't write the tasklist extension, so not sure if that's something that'll work or not.)

[gjtorikian]

but hopefully this is enough of a pointer

I C what you did there hyuck hyuck

Thanks a bunch! This helps a ton.

[kivikakk]

but hopefully this is enough of a pointer

I C what you did there hyuck hyuck

I can't even admit to doing that on purpose /o\

[kivikakk]

🎉

[oliverguenther]

Great stuff, thanks for working on this! 🙇‍♂️