Re: Questions about tree-sitter

[Eli Zaretskii]

> Date: Fri, 01 Sep 2023 14:45:31 +0530 (IST)
> Cc: emacs-devel@gnu.org
> From: Madhu <enometh@meer.net>
> 
> *  Eli Zaretskii <834jkecrl1.fsf@gnu.org>
> Wrote on Fri, 01 Sep 2023 09:53:14 +0300
> >> From: Madhu <enometh@meer.net>
> >> Date: Fri, 01 Sep 2023 08:09:27 +0530
> >> * Yuan Fu <C3EFD02D-F02F-4BE8-A6F4-A2506A9EFC90 @gmail.com> :
> >> Wrote on Wed, 30 Aug 2023 00:03:03 -0700:
> >> >> On Aug 29, 2023, at 2:26 PM, Augustin Chéneau (BTuin) <btuin 
> >> >> @mailo.com> wrote:
> 
> >> >> 1. Is there a way to reload a grammar?
> >> >> Emacs is pretty nice as a playground for testing grammars, but once a
> >> >> grammar is loaded, it won't be loaded again until Emacs restarts (as
> >> >> far as I know).  Is it possible to reload a grammar after modifying
> >> >> it?
> >> >
> >> > No, and it’s probably not easy to implement either, since unloading
> >> > the grammar would require Emacs to purge/invalid all the
> >> > node/query/parsers using that grammar.
> >> Does else see this a fundamental problem of the infrastructure, as it
> >> now relates to "becoming emacs"?
> > I don't think the capability to unload and reload is a necessary
> > requirement from any Emacs feature.  In particular, unloading a
> > feature is not always supported in a way that leaves a clean slate.
> > 
> > It is a good thing to have that, no doubt.  But not a hard
> > requirement, IMO.  Especially when the grammar is a C library, not a
> > Lisp library.  People who are testing grammars are advised to use
> > scratch Emacs sessions which are restarted when the grammar changes.
> 
> So I take it that these are shipped as black boxes: Presently if I
> have a probelem with say cc-mode I can attempt to patch and fix
> it. Likewise if I disagree about syntax with the package author say,
> whether I can get eldoc completion or evaluation within comments,
> because this is emacs and elisp, I am able to change things the way the 
> syntax is treated on the fly.

Yes.  Exactly like with other libraries we link against that are
maintained elsewhere: GnuTLS, the image libraries, libjansson,
HarfBuzz, etc.

> Am i right in apprehending that the move to treesitter is a change
> this aspect of emacs: that the user become merely a user of the
> product shipped by the llvm investors, and the consumption behaviour
> is to be determined and dictated by the investors (who arrange to ship
> black boxes) typically following the consumer patterns on the other
> industry standard editors

It is not a change, no.  See above: we already use quite a few of
libraries for specific jobs related to important Emacs
functionalities.  For example, good support for sophisticated text
display and shaping features is unimaginable without HarfBuzz, and
some scripts cannot even be displayed in a reasonably legible way
without it.

But since some users clearly prefer the ability to make changes by
modifying Lisp over the advantages of features based on true parsing
of the programming language, we will not be removing the major modes
based entirely on Emacs Lisp any time soon.