Re: Tree-sitter integration on feature/tree-sitter

[Yuan Fu]

> On May 8, 2022, at 12:16 PM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
>> 
>> My understanding was that tree-sitter can load these *.js parsers as
>> they are downloaded from the respective sites, or that there are tools
>> available to compile them if needed.  Why cannot we leave it to users
>> to do that by themselves, instead of using an Emacs module?
> 
> Oh right, now I understand.  The tree sitter implementation doesn't use
> an Emacs module any longer.  It uses the language definitions libraries
> like any other editor.  If you use the tree-sitter-module script you
> should use the 'batch-new.sh' script. This only creates a .so file.  My
> guess is that you could use any guide on the internet to compile such a
> shared object, then use it in emacs.  It seems to be a bit picky on the
> naming; it needs to be called 'libtree-sitter-LANG.so', which should
> probably be documented somewhere.  I cannot see that it is, yet.

libtree-sitter-LANG.so/dylib/dll seems to be the convention for language 
definition libraries. If there are irregular ones, one can use 
treesit-load-name-override-list to accommodate that (which is documented in the 
manual).

> 
> So in short: Emacs cannot load the .js directly, but when downloaded
> they should be compiled to a .so/.dll/.dylib and put somewhere emacs can
> see it, such as ~/.emacs.d/tree-sitter.  This could be left to the user,
> but it would be nice for emacs to do this, or at least a package in
> elpa/nongnu elpa that does this so that the barrier of entry isn't too
> high.

I don’t think anyone uses the .js grammar files directly, all the editors that 
support tree-sitter uses the compiled .so files, and .so files are what each 
language definition distributes. Also the compiler that compiles the .js 
grammar is written in IIRC nodejs, which I don’t want to come close to whenever 
possible.

Yuan