It is interesting to implement syntax highlighters- to solve the problem of making them fast and efficient. In JOE, I save the continuation of the syntax highl

It is interesting to implement syntax highlighters- to solve the problem of making them fast and efficient. In JOE, I save the continuation of the syntax highlighter parser for the beginning of each line. When the user changes the file, the file is re-parsed beginning with the continuation at the start of the line. Parsing stops early if the resulting continuation at the beginning of some subsequent line matches the saved value. JOE's highlighter supports recursive calls: for example to switch syntax to a scripting language embedded in HTML. Originally I implemented this with template instantiation of the sub-syntax. Recursion is allowed, but to a limited depth: the advantage is that the state can still be represented as a single number. Later, this was replaced with a real call stack. It turns out that the call stacks of the saved continuations are often identical (stated another way- there is already an identical continuation, so when there is a call, we search for and reuse it if found). The continuation also includes a buffer for saved data (for example for here document delimiters). The continuation ends up being 32 bytes on 32-bit machines: struct highlight_state { struct high_frame *stack; /* Closure */ int state; /* Program counter */ unsigned char saved_s[24]; /* Local data */ }; Anyway, it's at least conceptually straightforward to extend this to have any kind of state. Also, it should be possible to compile the syntax parser to the native machine code. Even so, the interpreted implementation is quite fast. Fast enough that there has not been a need to try to run it asynchronously or after a delay as in some other editors.