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

[Stefan Monnier <monnier@iro.umontreal.ca>]

Theodor Thornhill [2022-05-08 15:47:48] wrote:
> On 8 May 2022 12:33, Eli Zaretskii <eliz@gnu.org> wrote:
>  > Date: Sun, 08 May 2022 11:19:31 +0200 
>  > From: Theodor Thornhill <theo@thornhill.no> 
>  > Cc: casouri@gmail.com, emacs-devel@gnu.org 
>  > 
>  > You need the parser on a path emacs can see. Either we need to implement some
>  generic parser 
>  > installation functions in emacs, or we need this module or others like it. It compiles
>  the grammar and creates 
>  > a shared object that is read by emacs tree sitter. This is the tedious and error prone
>  part. 
>
>  I don't understand.  I thought tree-sitter itself was such a parser. 
>  Why do we need another one as an Emacs module? 
>
> Because the only implementation possible for emacs is the generic parser. It needs
> specific parsers to be inserted. The two are orthogonal, but related.
>
> Emacs cannot and should not contain such parser binaries. They are os and architecture
> specific. 
>
> Also, this way the parsers can more easily be fixed
>
> Does that make sense?

Not really, no.
You might want to be more precise about what you mean by "parser" and
explain what's the difference between the "generic parser" and more
specific ones.

By "specific parser" are you referring to something that I might call
"compiled grammars"?

The way I understand it, to use TS for a given language, you need:
- The TS runtime (which should be included in Emacs if you use the
  corresponding feature branch and which include what I'd called "the
  incremental parser").
- The language's grammar.  This is usually a .js file and is compiled to
  an .so file by the tree sitter tools.  This is *not* included in the
  feature branch (neither the grammars nor the tools).
- The glue in the major mode code.


        Stefan