The second commit provides a nicer user experience as the $ is not highlighted in red before the rest is typed.

I see that Scala 3 considers the string closed when there's an illegal $ token to be able to parse the rest. However, by working on the Pygments highlighter in parallel to this highlighter, I've come to the following insight: parsing/highlighting in real-time (like this highlighter does), and parsing a complete piece of code (like Pygments or the Scala compiler do) are different tasks, and can therefore treat errors differently.

To me, when a highlighter highlights more than I expect as a string, it's a very clear indication that I haven't closed the string properly. I think that's actually the best user experience for a case like this: it indicates very clearly the mistake that I made: the string is unclosed, and that's why I'm seeing the rest highlighted as a string. As soon as I fix that, I'll see the other parsing errors, if there are any. The feedback loop is very short here.

When running the compiler, or building a webpage where Pygments is highlighting code, the feedback loop is longer, so it may make sense to put more information about errors at once, but this sometimes comes at the cost of the clarity of the errors.

In the example with s"$; val a = "", there's a mistake, but no indication from the highlighter about it; I don't think that's the best behavior. Instead, I would suggest that we highlight illegal $ tokens as follows:

• The $ is treated as an interpolation marker
• The character after $ is treated as an illegal character
• If the string is unclosed, we keep highlighting the end of the line as a string. If it's possible to mark the \n as an error, that would be nice (does VS Code show something if we do that?)

This can be implemented as a very simple rule, something along the lines of (\\$)(.) as the final rule for string interpolation, and possibly another rule for \\n as an illegal token.

Now the highlighting is