Sourcepos data model

[tvanderstad]

Hey! In my work on lockbook I made made thorough use of comrak's sourcepos data, which has some bugs. I wonder if my experience can help.

One thing that's been standing out to me is that there doesn't seem to be one text range that contains the node. For a node that's nested in an outer block like a quote or list item, it seems to me that the prefixes added to each line shouldn't be considered part of the node itself. For example, consider this document featuring a multi-line strong node in a block quote:

> **line one
> line two**

When writing an editor, I need to answer questions like: is text under the cursor already bold? If so, the 'bold' button on the toolbar should be illuminated and clicking it should 'un-bold' the selection rather than bold'ing it. It's tempting to answer this question by checking if there is a strong node in the AST whose sourcepos contains the selection, but this currently includes the line prefixes added by container blocks like the block quote in the example. That means my toolbar button will behave poorly when I click somewhere in the prefix - the second > in the example is considered to be bold even though it's for a node that contains the strong node instead of being contained by it. To get Lockbook working, I added a bunch of tricky prefix logic that recursively figures out: on a particular line from the source document, how many characters belong to each of the container blocks?

I'm content to live with my tricky logic but, for the benefit of future comrak users, does it make sense to model source positions as a list of ranges from consecutive lines instead of a single range for the whole node? Would this kind of breaking change be a welcome contribution?

[kivikakk]

I'd very much be amenable to correcting the sourcepos model. We inherited it wholesale from cmark-gfm, where it was initially only implemented for inlines. I did my best to extend it to block elements there, but it never felt particularly fit for purpose (and there are some bugs remaining both there and in Comrak as a result).

The one thing is that it'd be helpful to preserve a way to produce the current output for those who currently rely on it, so they could keep up-to-date with Comrak without having to be ready to adjust their use first. This could just be a compatibility/translation layer, and I'd be happy to contribute this alongside your change if it did happen :)