← Back to context

Comment by chubot

1 day ago

Yeah after writing this highlighter, I started noticing what I consider bugs in other highlighters

e.g. although Vim's syntax highlighting helped me learn shell, it highlights numbers like 'echo 42' in a special way, which is misleading, because shell doesn't have numbers. (On the other hand, YSH does, but not in 'echo 42' either!)

On the other hand, there are also language design issues. Shell also allows MULTIPLE here docs, and I claim that ZERO syntax highlighters handle it correctly - https://github.com/oils-for-unix/oils.vim/blob/main/demo/bad...

(YSH removes here docs in favor of Python-like multi-line strings)

---

But the "surprise" in this article is that Vim is powerful, and you can write a good syntax highlighter or a bad one. There are many possible "programs" to write in this paradigm

I'd also say "completely accurate" highlighting doesn't really exist in practice, and is even problematic in theory.

Tree-sitter grammars are not completely faithful to the original language, because the metalanguage is limited. And highlighters have to deal with incomplete code, so it's not clear what "two parsers being the same" means.

Vim has the best syntax highlighting engine out there.

The approach of regions and match items which can contain each other in a hierarchy can handle anything.

By the way, I use Vim for web requests to highlight code served by CGIT.