[Bug] Commit diff syntax colors breaks in comments

[redsigma]

In the following python code snippet, if there is a multi line comment that doesnt include the ending """ block, it will not reset the syntax color for the future text.

After line 78 here should be normal python code colors, but it still shows the orange comment color on all of it.

This issue happens on both the side-by-side both and normal mode. If i modify the code a bit so the ending """ is visible in the code , then the problem disappears.

[love-linger]

It's a known issue. And I have no idea how to deal with it because the syntax highlight logic is hard coded in AvaloniaEdit component.

[mithom]

The real issue here is that the syntax highlighting only works on the visible text and not on the full file, resulting in broken highlighting.
This is indeed rather difficult to fix, but i was thinking if there is a possibility to (maybe automatically) change every start/end textmate blocks to also end on a lineskip segment, so that the highlighting starts over. I think this would (even though still not perfect) would already feel better than the opposite where a block stays too long.

(I've build myself some complex textmate for homebrew languages, so let me know if you want advise on this).

Anyone has an idea how other editors handle this issue? do they use more basic highlighting to prevent this issue, or consume more resources (valid reason not to copy it) to apply it on the real file and copy results or ...?

[love-linger]

One more thing that makes syntax highlighting complex is:

Even if all lines are displayed, there are still parsing issues. For example:

 /**
-  * This is a multi-line comment block
-  * One line with end */
+  * This is a multi-line comment block (modified)
+  * One line (end comment removed)
+  */

TextMate will mark One line with end */ as the end of a comment (because the */ marker is found)

The only solution is:

1. Parse each hunk individually
2. Parse the old and new parts with un-changed part separately within each hunk
3. Map the parsed results to the lines for final display

This makes the implementation of this feature extremely difficult.