Tree Sitter Guide
Last updated
Was this helpful?
Last updated
Was this helpful?
This is the documentation I've been following when making changes to the tree-sitter repositories.
At this time, Atom is our main focus for developing text editors for other spoken languages. The way Atom has set up their language recognition features (like syntax-highlighting, code folding, autocomplete and more) is through . As Atom.io is transitioning from the original TextMate grammars (this is the grammar used by other text editors like Sublime) that use regex for text matching to the new Tree-Sitter grammars, abstract syntax trees are the power behind the curtain.
Atom is currently in the process of transitioning all of their TextMate grammars to Tree-Sitter grammars, so Legesher at this time will be focusing on the newer tree-sitter language grammars and building on top of them. Eventually, we hope to expand to VSCode (which uses their own API of sorts for AST) and Sublime (which uses TextMate).
Whether or not you're new to abstract syntax trees or tree-sitter or Legesher, has been really helpful for the team to understand tree-sitter grammars and how it relates to Legesher. If you ever get lost in the fine tune details of the commands we're running, why the structure is the way it is, etc. this would be a great resource to turn to.
Here is the list of steps we'll go through in order to setup a new language's tree-sitter repositories.
Please refer to the for the most up to date requirements for tree-sitter grammar set-up.
Install node-gyp
Follow these instructions to on your computer.
Install node-gyp
as a global module by running the npm install -g node-gyp
command
Clone the new tree-sitter-legesher-LANGUAGE
grammar repository
git clone https://github.com/tree-sitter/tree-sitter-legesher-LANGUAGE
- NOTE: this is the normal convention of the tree-sitter grammars, but as they add more languages their might be exceptions to the naming convention.
Navigate to the root of this project in a terminal/command prompt
Run npm install
Add ./node_modules/.bin
to your PATH
NOTE: you can check if that is added correctly to your PATH variable by running echo $PATH
If you don't add this, prefix all tree-sitter commands with ./node_modules/.bin/
; e.g., tree-sitter
generate becomes ./node_modules/.bin/tree-sitter generate
Windows users need to replace forwards slashes with back slashes. You can do this by typing export PATH=./node_modules/.bin:$PATH
.
Run tree-sitter generate
Run node-gyp configure
Run node-gyp build
Run tree-sitter test
**corpus**
: this is where test files of how the programming language is implemented and used. Below is a list of possible files you can expect to find within this folder.
declarations.txt
expressions.txt
literals.txt
statements.txt
types.txt
**examples**
: this is a folder of test files for checking the validity of the grammar with real use cases.
**script**
: this is where language specific use cases are introduced and explained.
**src**
: this is where all the magic happens. More information on this folder later.
**grammar.js**
: key file that denotes the grammar, we'll be using this more going forward.
Alright, so here's where it gets fun! 🎉 This is where we will find all of the keywords / reserved words in the respective programming language and template them out. (would love for this to be abstracted out eventually)
Getting Keyword List
Within the repository, navigate to /lib/config/locale/language-template.yml
to see all of the keywords / reserved words for each language
Find the programming language that matches the tree-sitter grammar you're creating
For every word in that list under # << Keywords >>
, we will go through the tree-sitter grammar repo and template out. (this would be a great idea for automation)
Templating Tree-Sitter Grammar The templating agent we are using looks for testKEYWORDlegesher
, so as you traverse through the following files every time you encounter a keyword (there are some exceptions) surround it with the words "test" on the left and "legesher" on the right. I'll keep note of exceptions that happen for more than one language, but the tests are a great indicator that a keyword was missed or incorrectly templated out.
grammar.js
All of the necessary keywords to change should happen within the module.exports = grammar(test)
section of the file. A good thing to note, is that most of the keywords you will be templating out are in 'string'
format.
Some keywords are within a seq()
function like this lambda function below:
Others are simply in a prec.left()
function:
/corpus/*.txt
For these text files, it's a little bit more complicated than a simple cmd-f
keyword. Here's an example of the await
and return
keywords being templated out in the abstract syntax tree explanation of how an await expression is handled.
/examples/*
These are the test files that the grammar will run through to make sure the abstract syntax tree of the grammar is sound. Some of these files are extremely long, while others are a few lines. This is where the syntax highlighting may get a little off depending on the keyword you are templating. This is okay - rather this shows that the work you're doing is making a difference! This will give us a good test for our syntax highlighting later on as well.
Project Check (this is adapted from __)
Navigate to the project