bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot

["João Távora" <joaotavora@gmail.com>]

On Tue, Apr 18, 2023 at 2:25 AM Dmitry Gutov <dmitry@gutov.dev> wrote:

> > It was about the criteria for which versions of core packages to ship
> > with a release.
>
> I don't think we can get a single set of criteria across core packages.

Agree.  We should have categories and understand what is surprising
or workflow-breaking and what is not.

> BTW, if you recall the threads before Eglot was added, I was against
> that, and one of the things I cited is an LSP client has inherently high
> development velocity. Maybe the LSP community will settle/mature/stop
> adding features one day, but it's not there yet.

Very true, but the conclusion is only half-true.

It didn't have to be like this: Eglot _can_ grow rapidly in master
and and have its periodic stable releases.  And in the major Emacs
versions released to the public could have an even stabler release
(because it went through more testing).  This is just like any other
:core package until now.

The solution picked for this issue is bad in that it breaks some Eglot
users workflows and expectations when using very common configuration
recipes.  We should revert it and pick a fix that relies on recognizing
that there are different "sets of criteria" as you propose.  One
such fix remains uncriticized and unchallenged in this thread.

But if that doesn't happen, we shouldn't make a bad situation worse,
by backporting 100's of lines of code of Eglot and friends into Emacs 29.
That's the polar opposite in the pursuit of stability.  Hand-picked
bugfixes for problems manifesting themselves in Emacs 29, sure! But
wholesale changes are just asking for trouble and destroying the
value of the pretest and RC periods.  As bug#62907 shows, there are
certain edge-case bugs due to refactorings in upcoming Eglot 1.15
that are not in 1.12.29 bundled with Emacs 29.  Good! That's the way
it should be. Let's not ruin that.

> >> Because since we've decided in favor of stability of package.el, and
> >> against eglot's easy upgradability, I would suggest to backport Eglot
> >> 1.14 to emacs-29.
> >
> > I won't object.  In fact, I asked up front why not.
>
> Note that that suggestion comes with a fix to eldoc which you so far
> have rejected for emacs-29.

...to name but one change to the non-Eglot, already-there-in-Emacs-28,
libraries Eglot depends on (or will depend on).

I do think _that_ ElDoc fix should be just backported.  It's not
a complicated fix by any measure, it's easy to test, and it indeed
has value and safety.  Together with your similar fix for Company,
it'll make Emacs 29 users happier.

João