Re: Update on tree-sitter structure navigation

[Dmitry Gutov]

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