Tree-sitter: an incremental parsing system for programming tools

Re:Tree-sitter: an incremental parsing system for programmin... by brundolf on Monday February 22, 2021 @12:06PM (#26226930)

Here's what it looks like to call it from Rust: https://github.com/tree-sitter/tree-sitter/tree/master/lib/b...

Seems like this would make it much easier to bootstrap a performant language-server. Very cool; maybe that will be my next project.

[ Parent | on HN ]

Re:Tree-sitter: an incremental parsing system for programmin... by dcreager on Monday February 22, 2021 @12:33PM (#26227353)

We also have several of the language grammars published as crates: https://crates.io/search?q=tree-sitter (And doing the same for other grammars is a fairly painless process.)

So if you're writing a tool for a single language (like a language server), it should be as easy as adding tree-sitter and tree-sitter-blah to your cargo manifest.

[ Parent | on HN ]

Re:Tree-sitter: an incremental parsing system for programmin... by brundolf on Monday February 22, 2021 @12:57PM (#26227747)

Awesome! Though my thinking was that it would have an especially large impact for languages that aren't popular enough to have their own LSP yet; you no longer have to be an expert in writing interactive compilers to set up a respectable LSP for a niche language, or even a home-grown one

[ Parent | on HN ]

Re:Tree-sitter: an incremental parsing system for programmin... by dcreager on Monday February 22, 2021 @01:25PM (#26228204)

Yes! This is a great point. It's similar to what I mentioned over on this thread [1] about how we're working on a more precise version of Code Navigation based on tree-sitter. The tl;dr is that you'd write something like tree-sitter queries [2], just like you do for the current fuzzy Code Nav, but the query DSL would be a bit more sophisticated, allowing you to specify the actual name resolution rules of your language. One of the things we're using to test this is an LSP shim that lets us test our rules in VS Code (or any other LSP-compliant editor).

[1] https://news.ycombinator.com/item?id=26227476 [2] https://tree-sitter.github.io/tree-sitter/using-parsers#patt...

[ Parent | on HN ]

Re:Tree-sitter: an incremental parsing system for programmin... by ubolonton_ on Monday February 22, 2021 @11:35PM (#26233860)

> the query DSL would be a bit more sophisticated, allowing you to specify the actual name resolution rules of your language.

This sounds very interesting. Will the query DSL (spec) be available to the public?

[ Parent | on HN ]

Re:Tree-sitter: an incremental parsing system for programmin... by dcreager on Tuesday February 23, 2021 @10:04AM (#26238069)

That's the current plan! In particular, because we want to allow language communities to implement support for their own languages, and not have to be blocked on my team finding the time to do it. (Just like they can do now with the parser and syntax highlighting / fuzzy code nav rules.) Linguist is our role model here — it currently includes language detection and (regex-based) syntax highlighting rules for 500+ languages. Most of those are contributed by the community. There's no way that my team can migrate all of those in any reasonable amount of time, especially while having to balance that with other feature development and operational responsibilities.

[ Parent | on HN ]