Explainer: Tree-sitter vs. LSP
13 points by anup
13 points by anup
I don't think it'e entirely fair to say that LSP "solves" M x N. In this case M and N are tools and languages. LSP is not prescriptive in terms of languages -- you can use it with pretty much whatever language you want. But it is quite prescriptive in terms of tools! It provides support for maybe ~7 specific tools depending on how you count: Go To Definition, Find References, Render toolip, Render outline view, Autocomplete, Semantic Tokens, and Code Actions.
These are basically exactly and only the features you need to build something that looks and feels like a clone of VSCode. It's not M x N, it's more like 7 x N. This both suits Microsoft's strategic use for LSP (cement VSCode's market dominance) and their stated engineering design principles which are "bake the UI and UX into the protocol" which can only lead to that outcome.
One other thing tree-sitter could be used for, but I haven't really seen it used for yet, is providing syntax-aware editing for non-Lisp languages the way paredit does for Lisp. I use an Emacs package called smartparens that tries to add it to all programming modes, but it's possible for operations like slurp and barf to leave your file in a state that's not syntactically valid, unlike paredit.
I write very little Lisp and I am not intimately familiar with paredit, but I believe that the combobulate Emacs package by Mickey Petersen may be what you are looking for.
Oh yes, that's right. I had heard of that, and forgot about it because I can't get tree-sitter working in the environment in which I actually need it.
One other thing tree-sitter could be used for, but I haven't really seen it used for yet, is providing syntax-aware editing for non-Lisp languages the way paredit does for Lisp.
tree-sitter is what powers cursorless. See also https://lobste.rs/s/l4em19/cursorless_spoken_language_for_editing.