all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: casouri@gmail.com, emacs-devel@gnu.org, danny@dfreeman.email,
	theo@thornhill.no, jostein@secure.kjonigsen.net, dev@rjt.dev,
	wkirschbaum@gmail.com, pedz@easesoftware.com
Subject: Re: Update on tree-sitter structure navigation
Date: Sat, 09 Sep 2023 09:32:00 +0300	[thread overview]
Message-ID: <83sf7nvov3.fsf@gnu.org> (raw)
In-Reply-To: <dcdca65e-9b30-3d54-9556-d47d32328034@yandex.ru> (message from Dmitry Gutov on Fri, 8 Sep 2023 23:52:48 +0300)

> Date: Fri, 8 Sep 2023 23:52:48 +0300
> Cc: emacs-devel@gnu.org, danny@dfreeman.email, theo@thornhill.no,
>  jostein@secure.kjonigsen.net, dev@rjt.dev, wkirschbaum@gmail.com,
>  pedz@easesoftware.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > FTR, I have nothing against this technique, I just said that it will
> > need volunteers to assume this non-trivial job for each major mode,
> > and therefore I personally don't believe this to be a reliable
> > solution in practice.  But if volunteers step forward to do this, I
> > don't object.
> 
> I don't see a way around it, if the grammars continue to add breaking 
> changes.

If the only way we see is impractical, this doesn't help, does it?

> We already have volunteers: when somebody works on a ts mode (adds a new 
> feature or verifies that the current font-lock and indentation work 
> fine), might as well put in the last-known-good commit hash. Or update 
> it, if needed (e.g. the new feature requires that).

No, that'd be worse than what we have now: those commit hashes will
quickly become outdated (most grammar libraries are very actively
developed), and create the false impression that any later version will
not work.

The job is to track all the commits of the corresponding libraries and
keep the last commit known to work constantly up-to-date, with delays
that are at most days, not weeks or months.

> What I'm saying is in this case not doing this job well (e.g. updating 
> the commit hashes and font-lock/indent rules very rarely) might still be 
> better than not doing it at all.

I strongly disagree.  I think that doing this job not well is _worse_
than not doing it.  It takes just a few days, sometimes a couple of
weeks, from submission of the report about a breakage till a fix is
available, so people could install it soon enough and be done (since
these modes are not preloaded).  And we always strive to fix these
breakages in a way that makes the code more immune to further changes,
so there's hope that with time the frequency of these problems will
become lower.



  reply	other threads:[~2023-09-09  6:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-02  5:01 Update on tree-sitter structure navigation Yuan Fu
2023-09-02  6:52 ` Ihor Radchenko
2023-09-02  8:50   ` Hugo Thunnissen
2023-09-02 22:12     ` Yuan Fu
2023-09-06 11:37       ` Ihor Radchenko
2023-09-08  0:59         ` Yuan Fu
2023-09-02 22:09   ` Yuan Fu
2023-09-06 11:57     ` Ihor Radchenko
2023-09-06 12:58       ` Eli Zaretskii
2023-09-08 12:03         ` Ihor Radchenko
2023-09-08 13:08           ` Eli Zaretskii
2023-09-08  1:06       ` Yuan Fu
2023-09-08  9:09         ` Ihor Radchenko
2023-09-08 16:46           ` Yuan Fu
2023-09-03  0:56 ` Dmitry Gutov
2023-09-06  2:51   ` Danny Freeman
2023-09-06 12:47     ` Dmitry Gutov
2023-09-07  3:18       ` Danny Freeman
2023-09-07 12:52         ` Dmitry Gutov
2023-09-08  1:04   ` Yuan Fu
2023-09-08  6:40     ` Eli Zaretskii
2023-09-08 20:52       ` Dmitry Gutov
2023-09-09  6:32         ` Eli Zaretskii [this message]
2023-09-09 10:24           ` Dmitry Gutov
2023-09-09 11:38             ` Eli Zaretskii
2023-09-09 17:04               ` Dmitry Gutov
2023-09-09 17:28                 ` Eli Zaretskii
2023-09-12  0:36                   ` Yuan Fu
2023-09-12 10:17                     ` Dmitry Gutov
2023-09-08 21:05     ` Dmitry Gutov

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=83sf7nvov3.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=casouri@gmail.com \
    --cc=danny@dfreeman.email \
    --cc=dev@rjt.dev \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=jostein@secure.kjonigsen.net \
    --cc=pedz@easesoftware.com \
    --cc=theo@thornhill.no \
    --cc=wkirschbaum@gmail.com \
    /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.