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

[Andrei Kuznetsov <r12451428287@163.com>]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> The "generator" and the "runtime" are two separate programs, with
> separate functions, used at different times.
>
> The generator takes the javascript language grammar file and translates
> it (thru lots of hairy computations) into code that builds a parse table
> and other data structures. The tree-sitter generator outputs that code
> in C; it might be possible to adapt it to output in elisp (the wisitoken
> generator used to output elisp, but i gave that up when I implemented
> error recover in Ada; elisp is way to slow for that).
>
> The "runtime" uses the parse table to parse text at runtime, in response
> to user actions on the buffer. To be useful in an interactive editing
> context, it must have robust error recovery. What is your error recovery
> algorithm?

Currently extremely naive.  After an error occurs, it skips productions
until it can parses without errors, and just continues from there.  I
plan to improve it somewhat in the near future.

> Are you talking about the generator or runtime here?

The runtime.  The parser generator does not seem to be astonishingly
fast, but I don't think most people will have any cause to run it very
often.

> That's the runtime. Actual time for xdisp.c, preferably compared with a
> tree-sitter parse run on the same machine, would be helpful.

I'm currently pre-occupied and unable to work on this, but I will return
with these measurements as soon as reasonably possible.

> How long does the generator take?

I did not measure that, but as most people would be loading compiled
parsers, and not running the generator, I don't think it would matter
too much.  FWIW macroexpansion of the macro `defgrammar' blocks Emacs
for a second or 2.

> This seems to imply that the runtime supports incremental parse, so it
> does not reparse the whole buffer each time; is that true?

Indeed.  I've not yet figured out a particularly good way of recording
changes though -- as of present it relies on its own versions of
self-insert-command, kill-region, et cetera.