Atom understands your code better than ever before
It seems interesting to compare&#x2F;contrast this Tree-Sitter toolkit&#x2F;approach with the Language Server Protocol [1] work that VSCode has been taking. My gut impression is that the VSCode assumption that a language&#x27;s own compiler is often the best source of truth regarding that language, and using an information &quot;onion&quot; of fast &quot;traditional&quot; syntax highlighter augmented with the ability to request a more detailed version from a language compiler&#x2F;interpreter is a better approach for long-term maintenance reasons, if nothing else.<p>Admittedly, Tree-sitter has the opportunity to centralize some of the work in incremental parsing that LSP pushes to individual language tooling, but arguably in the modern world of watch-based programming most language tooling is going to feel a need to build it regardless.<p>The maintenance headache, though, is that Tree-sitter has its own custom grammar DSL, which likely won&#x27;t look anything like or share anything with the native grammars of the languages it is parsing, and which ultimately has to settle for a lowest-common denominator approach to grammar parsing. Even if it is more sophisticated than so-called &quot;crude&quot; RegEx-based syntax highlighters, it can still at best be a separately maintained emulation of a language&#x27;s grammar versus the LSP encouraging a language to provide its own intelligence presumably from the very same parser it uses to get work done.<p>[1] <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;visualstudio&#x2F;extensibility&#x2F;language-server-protocol?view=vs-2017" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;visualstudio&#x2F;extensibility&#x2F;...</a>