alt Hacker NewsThe use case isn't highlighting a huge amount of code, but local re-entrant highlighting.
You generally never need to highlight a whole file, only the part you're looking at. Which by definition must be fuzzy since you don't have the full source, the part you see will not parse as a complete program so you need to guess. This is actually one of the nastier parts of writing a highlighter, and it must be done for every language.
The lesson is that if you're going to be fuzzy you might as well be learned too and the results are pretty good.
This is more useful than it appears at first glance. It would be just as useful running on the CPU, which I'm sure it can.
Replies
> the part you see will not parse as a complete program so you need to guess
Presumably this could also be a useful trait when live highlighting of files when editing, as in-progress typing is likely to be unparseable sometimes.
No need to guess... For basic system highlighting, one can store the lexer context periodically (maybe per line) and invalidate it if edits are made before it. For more advanced stuff, you need a more complete parser anyway and do it asynchronously (LSP...).
Is that really the use case for the related packages mentioned on their website? highlightjs and prismjs are typically used to highlight code snippets on websites… which are at most a few hundred lines long. And are usually highlighted as a whole