-
-
Notifications
You must be signed in to change notification settings - Fork 555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow parsing into an existing node #524
Conversation
@jgm @nwellnhof does this look better? |
src/cmark.h
Outdated
/** Creates a new parser object with the given node to use as the root | ||
* node of the parsed AST. | ||
* | ||
* This is useful for creating a single document out of multiple parsed | ||
* document fragments. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading this, I wondered: what happens if the specified root node already has children? What happens then? Do the new nodes get added to the end of the children? Or do they replace existing children? Maybe the comment should be explicit about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They appear after, see add_child
in blocks.c
.
I do wish it and cmark_node_append_child
shared code though to make that clearer, however.
Same could be said for make_block
and cmark_node_new
.
- The current page seems rendered at 72 chars, so match that. - `---` and `--` in the convert dashes docs were being converted, so it looked like a no-op! (i.e. em dash becomes em dash, en dash becomes en dash.)
a1426e2
to
d380eca
Compare
I noticed that |
cmark.3 is updated as part of |
I would prefer an API like
mainly because it makes it easier to support this feature in language bindings. For memory management, the reference from the parser object to the node object must be tracked and the Besides, it would get more and more clumsy if we wanted to support additional settings in the parser constructor. I'm aware that it's cleaner to avoid mutation of parser state and to set all options when constructing the parser object. Functions like |
What if we had a |
Exposing structs in public APIs should be avoided because modifying the struct in future versions would break the ABI. There are some tricks like adding a version field to the struct but that's rather ugly. The cleanest solution is to have a separate object for parser settings, leading to something like
For a real-world example look at |
Ooo I like that. Making another opaque type to keep some state out of the parser feels good to me. Fewer edge cases, etc., and not too hard to to clients still. |
Needed until commonmark/cmark#524 is released. • Added input 'cmark': 'github:commonmark/cmark/cd37711b8a08da67ba4e21a42614b86dd8def929' (2024-01-26)
Needed until commonmark/cmark#524 is released. • Added input 'cmark': 'github:commonmark/cmark/cd37711b8a08da67ba4e21a42614b86dd8def929' (2024-01-26)
Needed until commonmark/cmark#524 is released. • Added input 'cmark': 'github:commonmark/cmark/cd37711b8a08da67ba4e21a42614b86dd8def929' (2024-01-26)
Variation on #522 for same purpose. A good deal smaller. First commit is implementation, second commit is test.