Re: [SPAM UNSURE] Maybe we're taking a wrong approach towards tree-sitter

[Arthur Miller <arthur.miller@live.com>]

Andrei Kuznetsov <r12451428287@163.com> writes:

 Leake <stephen_leake@stephe-leake.org> writes:
>
>> That's true for the common TS runtime, which implements the parser and
>> error recovery, but the code for each language, that builds the LR parse
>> table and some other data structures, is generated in C from a grammar
>> file written in javascript, and must be linked into Emacs somehow. In
>> addition, some languages require an "external scanner", which is more
>> code in C that is specific to the language.
>
> Interesting.  I assume it would be possible to reuse the source grammar
> files?

It probably is, and looking at neowim's gh repo, there are some
instructions on how to create a grammar for new language:

https://github.com/nvim-treesitter/nvim-treesitter

The process could probably be somehow automated from lisp.

I have though a sincere question about this entire tree-sitter
venture. Is it really worth trouble in Emacs case? As I understand TS it
is a specialized regex matcher, and looking at some language specs leave
me with that feeling (for example the grammar for bash):

https://github.com/tree-sitter/tree-sitter-bash/blob/master/src/grammar.json

I undestand that having specialized regex matcher is more efficient than
some generalized regular matcher current font-locking in Emacs relies
upon, but is it *that* more efficient to be worth the extra troubles?
TS seem to keep state (a node) for each character typed, that will be a
lot of memory consumed in some big files. If this syntax tree it keeps
to implement what it does can be re-used for something else than it
could be very useful, but just for syntax-highlight and indentation?
Some years ago, when opening some 10k lines as found in Emacs src dir, I
noticed some slowdown on font lock. But nowadays I don't experience any
hickups with syntax hightlighting or indentation.

Anyway, it is very educating to see TS get merged into Emacs and to read
Eli's tips and guidance about Emacs internals.