Implications of elixir-lang tree-sitter grammar?

What implications for elixir tooling does GitHub - tree-sitter/tree-sitter: An incremental parsing system for programming tools have? Forgive the vague question, - this isn’t an area I know much about, but I’m curious about what might be enabled.

I was wondering, for example, about additions to elixir-ls. A few months back I was interested in adding elixir-aware selection expansion to vscode (something I miss after having it in other languages). There’s a github issue for this: Support for textDocument/selectionRange API · Issue #534 · elixir-lsp/elixir-ls · GitHub. I didn’t pursue the thought far, as it was clearly beyond my elixir knowledge, but the impression (quite likely wrong) I got from a quick survey was that new additions to elixir-ls need to do their own parsing. Would there be scope here for using tree-sitter (assuming the present or future existence of elixir bindings)?

Or are there other areas of elixir tooling where tree-sitter would be useful?

2 Likes

IIRC that need for hand-parsing was a primary motivator for the new Code.Fragment machinery that was just released in Elixir 1.13 (earlier this month).

2 Likes

I asked the same thing on twitter, and got a great answer

4 Likes

GitHub code-navigation just went live for Elixir and it uses the tree-sitter grammar under the hood :tada:

6 Likes