I was encountering a codemirror view issue that only happened with block wrappers + syntax tree not being available on the current position, but the view issue was resolved by this recent patch, so thank you again to marijn! This leads me to my question about the syntax tree update behavior. In my case, I was encountering it on a slightly long document, and specifically when editing a paragraph immediately under a bullet list.
This example tries to recreate this setting with an exaggerated document length to induce the behavior I was seeing (at least in my machine). Decorations also don’t try to be efficient in the example. Up until line 300, it’s all paragraph text, and there’s a bullet list after. In my machine, holding down a character key for a few seconds at line 326, which would be a paragraph under the first list, would cause a log in the console if the tree is not available at the current viewport position.
It looks like editing the paragraph immediately after the bullet list recreates the syntaxTree, or at least causes to update a large part of it. Editing inside list items, or adding a second paragraph after the paragraph immediately after the list does not cause this significant syntaxTree recreation. I was wondering if this is expected, or perhaps an issue/some other thing?
I’m not really sure what kind of behavior you’re talking about here. It would help if you could be a bit more clear about what you’re seeing and what you’re expecting.
Yeah sorry about that! Hope the info below is clearer. Screenshots taken from the codemirror try website. The gist is editing the immediate succeeding paragraph after a list seem to cause a major syntax tree update, but editing paragraphs after that (or the list item themselves) don’t.
There’s a viewplugin in the examplethat tracks the syntax tree length and prints some info at the console (screenshot below). In one case, the viewport.from is at 144k, and the list block is fully within the viewport. So I was expecting that the tree would at least be available at viewport.from. But the tree length is only at 57k. Although again this is only observed when editing the immediate succeeding paragraph after a list (at line 328 in the pic above). Editing at line 328 seems to preserve the tree up until viewport.from.
That’s related to the way the Markdown parser’s incremental parsing works. Because the paragraph after a list might become part of that list, when edited, it needs to re-parse the list. It doesn’t have a strategy for partially parsing a list, so it re-parses it entirely. In this case, the list is rather big, so quite a bunch of text is re-parsed.
I don’t think I’m following, so please bear with me. I’ll try to be explicit on what I’m confused on.
In the example used above, the 1st 300 lines (from positions 0 to 147,299) are paragraphs, and the first list is on lines 304 to 324 (positions 147,303 to 147,508). But when typing at line 326, the tree length can be in positions before the list and in the preceding paragraphs (in the screenshots above, tree length at one point was 57,937 which is well before the list at position 147,303). Would this mean that it’s also reparsing the preceding paragraphs? (I’m also understanding the tree length to be the parsed position, which might be incorrect.)
Oh, hm, the thing I described is how it is supposed to work, but on closer look it appears you’re running into a bug here, which is breaking efficient re-parsing. @lezer/markdown version 1.6.3 should help.
