Re: PL support

[Dmitry Gutov]

On 09.05.2020 22:28, Daniel Colascione wrote:
> On 5/9/20 12:01 PM, Dmitry Gutov wrote:
> > On 09.05.2020 21:41, Daniel Colascione wrote:
> > > TreeSitter requires NPM for customization and compiles to C, right? I 
> > > don't want people to require either to customize Emacs. Why not just 
> > > port the tree sitter parser generator to elisp?
> >
> > You might want to pop to the previous discussion of TreeSitter on this 
> > mailing list.
> >
> > I made these points there already, you're welcome to read the responses.
>
> I should go back and reread that. (I declared emacs-devel unread email 
> bankruptcy recently.)

I sympathize.

> > Bottom line is: if someone implements this, we can talk. 
>
> Does anyone need to implement it?

It doesn't work yet, does it?

> Looking at TreeSitter's repository, it 
> looks like the parser generator itself is written in Rust (which could 
> be linked directly into Emacs), the JS-specific grammar bit is pretty 
> small and directly translatable to elisp [1], and the output of the 
> parser generator is a bunch of tables that could, in principle, be used 
> directly instead of having to round-trip through a C compiler.

I guess the question is how fast this is going to work, compared to the 
original. Then the details of the Elisp interface. And also our ability 
to keep up with the grammars and TreeSitter's development (new features, 
api changes, etc).

In the meantime you can try out 
https://github.com/ubolonton/emacs-tree-sitter/ (they seem to have 
gotten syntax highlighting working now). That's a straightforward 
integration, though.

> If TreeSitter works as well as described, it'd be worth just making it a 
> build requirement for Emacs so that --- at long last --- the core modes 
> could be grammar-based. Doing that would require ditching platforms that 
> Rust doesn't support, but I'm okay with that. It looks technically doable.

Um, well... That sounds like a beginning of the "Rust in Emacs core" 
project as well. :)

> Sure, integrating TS this way would require taking a dependency on LLVM 
> --- at least for the moment, since gccrs is still immature. It'd be a 
> political shift. But is it more important to catch up with the rest of 
> the editingworld or to keep shunning LLVM (which is free software!) for 
> some reason?

I wouldn't want to rain on this parade, but I think we might need strong 
practical evidence of this approach before such a move would be considered.