4 ms·

We also have several of the language grammars published as crates: https://crates.io/search?q=tree-sitter https://crates.io/search?q=tree-sitter (And doing the

We also have several of the language grammars published as crates: https://crates.io/search?q=tree-sitter 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.

brundolf 6y ago
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
- dcreager 6y ago
  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 https://news.ycombinator.com/item?id=26227476 [2] https://tree-sitter.github.io/tree-sitter/using-parsers#pattern-matching-with-queries https://tree-sitter.github.io/tree-sitter/using-parsers#patt...
  - ubolonton_ 6y ago
    > 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?
    - dcreager 6y ago
      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.

brundolf 6y ago

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

dcreager 6y ago
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 https://news.ycombinator.com/item?id=26227476 [2] https://tree-sitter.github.io/tree-sitter/using-parsers#pattern-matching-with-queries https://tree-sitter.github.io/tree-sitter/using-parsers#patt...
- ubolonton_ 6y ago
  > 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?
  - dcreager 6y ago
    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.