That depends on how deep you want to go with the result. I use the Nova editor which uses tree-sitter for syntax highlighting, and I've packaged several languages for it. Each time it goes like this:

1. Clone someone's tree-sitter grammar off GitHub.

2. Build it into a Mac .dylib.

3. Create a Nova extension that says "use this .dylib to highlight that language."

4. Use it.

I don't have to make any changes to Nova itself, and the amount of configuration I have to write is so tiny that Nova could have a DIY wizard if they wanted it to.

The source for Difftastic discussed here (at https://github.com/Wilfred/difftastic/blob/master/src/parse/...) is also very simple: for each of a list of supported languages, import the tree-sitter parser and wrap a teensy amount of configuration around it.

> 3. Create a Nova extension that says "use this .dylib to highlight that language."

How is that possible if the different tokens emitted by tree sitter don't have standardized names? Isn't there some kind of configuration that maps the rules in the grammar to whatever convention Nova uses for their token names?

Now tree sitter does make this super easy, but my point was you still have to have some kind of per-language configuration/logic to work, whereas the entire point of LSP is to have none.

That's done with the "highlights.scm" query (https://tree-sitter.github.io/tree-sitter/syntax-highlightin...) that maps nodes to their types with lots of standard names (https://github.com/tree-sitter/tree-sitter/blob/master/highl...).

The maintainer of the tree-sitter grammar is usually one who maintains that mapping. At least, every time I've wanted to use it, it's been the case that all of that was already done and part of the grammar's repo.