TL;DR CRDT is completely irrelevant to any of the highlighting/etc stuff
Most highlighters are lexers.
Advanced highlighters/folders are parsers.
The lexing/parsing that is required for highlighting is easy to make incremental for all sane programming languages.
for LL(star) grammars, adding incrementality is completely trivial (i sent patches to ANTLR4 to do this)
for LR(k) grammars, it's more annoying but possible (tree-sitter does this)
For lexing, doing it optimally is annoying, doing it near optimally is very easy.
optimal incremental lexing requires tracking, on a per token basis, how far ahead in the character stream the recognizer looked (easy), and computing the affected sets (annoying)
Most real programming languages have a lookahead of 1 or 2.
Near-optimally requires tracking only the max lookahead used, and assuming all tokens need that max-lookahead. In a world where min token length is 1, that means you only need to re-lex an additional (max lookahead) tokens before the changed range. In a world where min token length is 0, it's all zero length tokens + (max lookahead) tokens before the changed range. This does not require any explicit per-token computation.
Again for basically all programming languages, this ends up re-lexing 1 or 2 more tokens total than strictly necessary.
Tree-sitter does context-aware on-demand lexing.
i have patches on the way for ANTLR to do the same.
The only thing CRDT helps with in this equation at all is knowing what changed and producing the sequence of tree-edits for the lexer/parser.
The lexer only cares about knowing what character ranges changed, which does not require CRDT. The typical model for this kind of edit is what vscode's document text changes provide (IE For a given text edit, old start , old end, new start , new end)
The parser only cares about what token ranges changed, which does not require CRDT.