emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SPAM UNSURE] Re: [SPAM UNSURE] Maybe we're taking a wrong approach


From: Stephen Leake
Subject: Re: [SPAM UNSURE] Re: [SPAM UNSURE] Maybe we're taking a wrong approach towards tree-sitter
Date: Thu, 29 Jul 2021 16:25:40 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt)

Andrei Kuznetsov <r12451428287@163.com> writes:

> Ergus <spacibba@aol.com> writes:
>
>> 1) Performance (discussed in the previous thread):
>
> FWIW I have been experimenting with an increcemental GLR parser
> generator in Emacs Lisp.  

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?

> While I have not put in the effort to couple it with font-lock and
> such, from anecdotal examination it does not perform badly with a
> naive C grammar. 

Are you talking about the generator or runtime here?

> The initial parse does take several seconds on large files, 

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

How long does the generator take?

> but afterwards I did not notice a significant drop in editor
> responsiveness.

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

>> 2) Not reinvent the wheel.
>
> While tree-sitter may be nice and all, it doesn't seem to offer the
> usual extensibility expected from Emacs.

It's all open-source, but it is very complicated and may be beyond many
people's ability to change correctly.

It requires running a C compiler to change it, but so do other parts of
Emacs (for example, the json parser).

So what is it missing?

-- 
-- Stephe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]