emacs-devel
[Top][All Lists]
Advanced

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

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


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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrei Kuznetsov <r12451428287@163.com>
>> Date: Wed, 28 Jul 2021 19:48:18 +0800
>> Cc: Stephen Leake <stephen_leake@stephe-leake.org>, emacs-devel@gnu.org
>> 
>> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>> 
>> > I too did not follow the tree-sitter discussion closely. But AFAIU,
>> > tree-sitter provides tools to generate a parser (in C) from a grammar.
>> 
>> If that is the case, it certainly seems grave! I don't think an Emacs
>> that requires source modifications for extending vital editing
>> functionality is a good idea.
>
> TS's code is written in plain C, and doesn't require any regeneration
> or source modifications.  Anything else is misunderstanding.

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.

Ideally, there would be some sort of plugin, so new languages could be
added at run-time; maybe we could add a protocol on top of emacs
modules. I don't know how Yuan is handling this now.

-- 
-- Stephe



reply via email to

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