all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Madhu <enometh@meer.net>
Cc: emacs-devel@gnu.org
Subject: Re: Questions about tree-sitter
Date: Fri, 01 Sep 2023 13:58:24 +0300	[thread overview]
Message-ID: <83zg26b1nz.fsf@gnu.org> (raw)
In-Reply-To: <20230901.144531.1741909029511895251.enometh@meer.net> (message from Madhu on Fri, 01 Sep 2023 14:45:31 +0530 (IST))

> 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.



  parent reply	other threads:[~2023-09-01 10:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 21:26 Questions about tree-sitter Augustin Chéneau (BTuin)
2023-08-30  7:03 ` Yuan Fu
2023-08-30 11:28   ` Augustin Chéneau (BTuin)
2023-09-06  4:07     ` Yuan Fu
2023-09-08 11:53       ` Augustin Chéneau (BTuin)
2023-09-08 16:43         ` Yuan Fu
2023-09-09 16:39           ` Augustin Chéneau (BTuin)
2023-09-12  0:22             ` Yuan Fu
2023-09-13 12:43               ` Augustin Chéneau (BTuin)
2023-09-14  4:11                 ` Yuan Fu
2023-09-18 17:04                   ` Augustin Chéneau (BTuin)
2023-09-19  4:00                     ` Yuan Fu
2023-09-01  2:39   ` Madhu
2023-09-01  6:53     ` Eli Zaretskii
2023-09-01  9:15       ` Madhu
2023-09-01 10:45         ` Dmitry Gutov
2023-09-01 10:58         ` Eli Zaretskii [this message]
2023-11-27  7:16           ` Madhu
2023-09-06 16:11   ` Lynn Winebarger
2023-09-07 23:42     ` Yuan Fu
2023-09-08  0:11       ` Lynn Winebarger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zg26b1nz.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=enometh@meer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.