This document describes what files and directories the repository
provides and associated reasoning. First it covers things which are
likely to remain in place for some time (except perhaps the src
directory). This is followed by a description of things that are more
likely to change or be removed.
One might be interested in this content out of academic curiosity but more likely it might be because one is thinking of depending on the repository in some way.
The order of the following files and directories is alphabetical and not meant to reflect relative importance.
-
CHANGELOG.md
- this file contains a changelog. -
COPYING.txt
- this file contains license information for the repository. -
grammar.js
- this file contains a grammar description and is used in the process of generating parser source code that lives insrc
. It's likely that this (or something comparable) will continue to be provided assuming tree-sitter doesn't change the way it works. -
package.json
- this file is needed by a component of Cursorless. It uses our grammar via yarn andpackage.json
seems to be essential [1]. -
queries
- this directory and the simple file it contains are provided on request fromdifftastic
folks. The file it contains doesn't contain much and is not likely to be the sort of thing one expects to be used in an editor. -
README.md
- this file contains the repository's README content. -
src
- this directory contains source files that are generated [2] fromgrammar.js
. The files are typically used to generate a dynamic library / shared object that can be used by the tree-sitter library to handle Clojure / ClojureScript source code. Although the content of this directory is generated, the files are provided because in practice, multiple parties have already become dependant on them. There have been opinions voiced that this should not remain so, but change in that direction has not been widespread. We would prefer not to be hosting this directory and its content, but are leaving it in place for the time being. See here for more on the topic if interested. -
test/corpus
- this directory contains tree-sitter's corpus test-related files.
The rest of the content of the repository is much more subject to change / removal so depending on such remaining in place is likely not a good idea.
ATM, some of that includes:
- documentation
- Node.js bindings
- Rust bindings
The bindings are not tested in any way and only really exist as a
side-effect of running the tree-sitter
cli's generate
subcommand.
They may be removed at some point, but they should be straight-forward
to generate as long as one has a suitable tree-sitter
cli and the
grammar.js
file mentioned above, but see below for details and/or
have a look at some official
docs.
Invoking tree-sitter generate
should lead to the creation of the
bindings/rust
directory (plus files within) and Cargo.toml
if
these don't already exist.
To build the bindings, use cargo build
for a debug build or cargo build --release
for a release build. The results should end up under
the target/debug
and target/release
directories respectively.
In order to successfully build the Node.js bindings (say, by an
invocation of npx node-gyp rebuild
), first do the following:
- Remove
package.json
(or rename it) - Invoke
tree-sitter generate
This will create a new package.json
with allegedly correct values
for properties like dependencies
and main
. It might be worth
tweaking some of the other properties such as version
to avoid
confusion. The generate
subcommand should also create binding.gyp
and the bindings/node
directory (plus files within), if these don't
already exist.
Once the new package.json
has been arranged for, invoking npm install
should lead to appropriate dependencies being installed.
Executing npx node-gyp rebuild
should then be enough to build the
Node.js bindings. The result should end up in the build/Release
directory.
Note that though I have tried the above instructions, I don't use or test the bindings and it may be that they will be out-of-date at some point. I suggest checking the aforementioned official docs or asking at the tree-sitter repository.
[1] The file package.json
may also be required if it's important to
use some of the capabilities of the tree-sitter
cli such as the
tags
and highlight
subcommands (which we don't typically use).
It's not necessary for all subcommands though (e.g. neither the
generate
nor test
subcommands seem to require it). Its presence
also doesn't signify necessary use of npm
.
Possibly contrary to what might be indicated elsewhere, npm
is
not necessary for certain core parts of tree-sitter grammar
development. However, at the moment, an appropriate version of node
is required for the generate
subcommand to work.
[2] If the grammar uses an external scanner, src
may contain
non-generated files such as scanner.c
, scanner.cc
, etc. In the
current case, no external scanner is used and the src
directory
content is entirely generated.