tree-sitter-elisp VS emacs-ng

Here is the tree-sitter grammar of Elisp:

https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... (approx. 200 lines)

and here is the grammar of JavaScript:

https://github.com/tree-sitter/tree-sitter-javascript/blob/m... (approx. 1200 lines)

JavaScript evolved into a language of similar complexity as Perl 5 (the corresponding tree sitter syntax table counts almost 2000 lines, currently).

> I like the multiprocess approach with standard protocols, despite its complexities, because it lets different editors share smarts.

Yes, the benefit LSP brings is putting editors/IDEs on equal footing with respect to a specific language. Also the multiplicative effect when the author of a new language provides a language server so nobody needs to switch their IDEs to try it out.

However, seeing how „straight forward“ a tree-sitter specific language grammar looks in practice (1) makes we wonder if by providing a TS grammar for a language would realize (almost) the same benefit. Based on such a grammar and TS’ selector engine figuring out a syntax highlighting scheme, code folder, a docstring or symbol scanner might not be such a huge endeavor any more as you described for ENSIME.

So, yeah, in the end LSP might be dead end at some point, especially because TS promises to be very fast and avoids any IPC. Performance seems to be the biggest problem of LSP clients in Emacs and probably other editors as well.

(1) https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... — of course, the example being ELISP makes it look easier than said, if you compare it with the grammar of Perl5 that’s not yet finished unsurprisingly.

This is exactly what emacs-ng does?

https://emacs-ng.github.io/emacs-ng/

> This project should be considered an additive native layer over emacs, bringing features like Deno's Javascript and Async I/O environment, Mozilla's Webrender, and other features in development. emacs-ng's approach is to utilize multiple new development approaches and tools to bring Emacs to the next level. It is maintained by a team that loves Emacs and everything it stands for - being totally introspectable, with a fully customizable and free development environment. We want Emacs to be a editor 40+ years from now that has the flexibility and design to keep up with progressive technology.

I guess it uses webrender instead of electron?

Now I'm failing on this instead: https://github.com/emacs-ng/emacs-ng/issues/218

Presumably because of emacs-ng [1], from the page " additive native layer over emacs, bringing features like Deno's Javascript and Async I/O environment, Mozilla's Webrender,".

[1] https://github.com/emacs-ng/emacs-ng