Re: Call for volunteers: add tree-sitter support to major modes

[Payas Relekar]

Po Lu <luangruo@yahoo.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Yes, more of an Emacs 30 thing, so 2024-ish.
>>
>> That is, during the next year, I'm guessing that we'll be gaining
>> tree-sitter support for all the major programming languages, and when
>> that is better than what we already have, we should consider making
>> tree-sitter a prerequisite for Emacs (and these modes) and rapidly phase
>> out the old code.
>
> I and many others will _very_ strongly object to removing the build
> without tree-sitter.  Emacs has never needed a non-system library to
> edit text, and that should not start now.
>
> On X, we even support the build without XCB, as even though it has been
> ubitous for decades, it is not specified in any document and cannot be
> implemented by third parties.  Unlike Xlib, which is part of the
> specifications for release 6 of the X Window System, version 11,
> published by the X Consortium.
>
>> It's also a question of how much user breakage we'll tolerate/aim for.
>> That is, there's a gazillion tuning knobs all over the modes to tweak
>> stuff that will be rendered obsolete by tree-sitter, and which people
>> may be fond of.
>
> It will certainly break a lot.  Last I heard tree-sitter itself has
> problems with complex macro constructs in C and C++ code.
>
> CC Mode has less, because it is too dumb to try to parse them.

Currently, the 'dumb' implementation is default and tree-sitter based
one needs to be setup and enabled by the user (however easy it may be).
If the tree-sitter is in core, and the old 'dumb' way is no longer in
core, can the current way be done the other way around? i.e. disable
tree-sitter from core for cc-mode and add current cc-mode as extra
package and use that the way currently external tree-sitter mode is
used? This way even if tree-sitter is build-time dependency, it won't
affect runtime.

C++ is notoriously difficult to parse for something like tree-sitter due
to context sensitiveness of operators, and I understand your pain. But
for languages with better syntax and semantics, it has been immense
improvement in performance and usefulness over the 'dumb' regex parsing.

--