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

[Dmitry Gutov <dmitry@gutov.dev>]

On 18/04/2023 14:44, João Távora wrote:

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

This particular one didn't have to, but it's a problem very 
characteristic of joining a strongly centralized project with ultimately 
one person having the last word in all major decisions. And it's not 
like Eli is being unreasonable: we do need a stability cutoff, and we're 
really long past it. These one-more-change kind of arguments repeat year 
over year, with reasonable, well-intentioned people on both sides.

I don't see any better solutions than better modularity (which delegates 
responsibility by its nature) and/or more frequent releases somehow.

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

Sure, and I agree, but I don't really see how to present that in terms 
Eli would feel suitable to accept. One "trick" that worked in the past 
was to somehow enumerate all potential execution flows (functions 
involved, etc) that would be affected by the change.

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

I don't insist, not at all. It was just my own impression of what would 
constitute a reasonable Eglot release that we could be satisfied with 
having a large number of people use without upgrading, for years. Issues 
like blinking eldoc messages, or eldoc messages that can take up half 
the height of the window seem like things that we wouldn't want in it.

Perhaps the second issue affects only a minority of servers, and I'm 
wrong to be worried. Because otherwise, I really don't understand why it 
hasn't been reported and fixed until recently. Not blaming you, just to 
be clear.

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

That's what I'm thinking, too.