all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
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, 9 Sep 2023 20:04:07 +0300	[thread overview]
Message-ID: <b048a654-3c39-c960-7ece-d641b6586ea9@yandex.ru> (raw)
In-Reply-To: <83a5tvvaoo.fsf@gnu.org>

On 09/09/2023 14:38, Eli Zaretskii wrote:
>>> 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.
>>
>> But it's not the first thing the user sees, just internal information:
>> we tested with this version last, it's known to work, so if you want to
>> have a known well-working configuration, you will install this one.
>> Might as well install the latest and try their luck, though.
> 
> How is it useful to ask users to use, say, 2-year old versions of
> grammar libraries, especially for languages where either the language
> or the library (or both) change quickly?

It would be better to use a 2-year-old grammar which works with our mode 
than a new grammar which breaks our mode anyway.

We could also take a slightly more advanced approach: first install the 
latest version (if the user goes for 'M-x 
treesit-install-language-grammar' right away), and then in case of query 
errors suggest the version of the grammar known to work. But that's 
extra complexity (and more actions on the part of the user as well), and 
the actual benefit is hard to foretell.

>> Further, most important grammars seem to be in a reasonably complete
>> state by now.
> 
> They add features and fix problems all the time.  So I disagree with
> the "reasonably complete" part, and so are the developers of those
> libraries, evidently.

Depends on the individual language, of course.

>>> 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.
>>
>> Consider that js-ts-mode is "broken" in Emacs 29.1 now with the latest
>> grammar. If there was the last-known-working hash, we could offer the
>> users a friendlier way to install it.
> 
> How is it friendlier to downgrade to an older version (which would
> require fetching it, building it with a C compiler, and installing it)
> than to patch a single Lisp file?  Actually, people don't even need to
> patch their Emacs installations, they could instead have a fixed
> version of the Lisp file in their home directories or in site-lisp.

So we'll suggest they manually copy the latest version of xxx-js-mode.el 
from master over to their site-lisp? That will be our recommendation in 
case a grammar breaks?

I suppose we could publish all ts grammars in "core ELPA". Then the 
recommendation will be "just upgrade from ELPA" (though keeping in mind 
the associated usability problem like the one we discussed with Eglot). 
"Core ELPA" also inflicts certain restrictions on how the code in the 
package is written (backward compatibility checks, etc).



  reply	other threads:[~2023-09-09 17:04 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
2023-09-09 10:24           ` Dmitry Gutov
2023-09-09 11:38             ` Eli Zaretskii
2023-09-09 17:04               ` Dmitry Gutov [this message]
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=b048a654-3c39-c960-7ece-d641b6586ea9@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=casouri@gmail.com \
    --cc=danny@dfreeman.email \
    --cc=dev@rjt.dev \
    --cc=eliz@gnu.org \
    --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.