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

[Dmitry Gutov]

On 18/04/2023 23:56, João Távora wrote:
> On Tue, Apr 18, 2023 at 9:38 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> > 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.
>
> Yes. And here both people sides "one more change".  The change that _did_
> make it in is more aggressive and more unstable than the one that didn't.

Well, not really. It's by definition more conservative one. Problem is, 
it violates a practice established by third-party community outside of 
Emacs.

> > 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.
>
> Right.  And IMO it's not a "trick", it's how it should be.  It's hard to prove a
> negative, but at least it should be attempted.  Well, the patch I presented
> (the one you +1'ed) makes it so that package-install keeps exactly its previous
> behaviour unless its argument is one of (eglot use-package), which are arguments
> that could not have ever been passed to that function as :core packages
> in Emacs 28. M-x package-install RET seq or (package-install 'xref) keep EXACTLY
> the same behaviour.  It's very clear to see from the minimal patch.

Perhaps a more structured/verbose outline of the same would help.

Although apparently the example I was thinking of 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774#479 and the 
surrounding thread) occurred when the corresponding pretest hadn't 
started yet.

> > 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.
>
> The issue has existed and has been worked around successfully for a long
> period of time.  It's not actually a problem, it's a consequence of the
> default values for eldoc-echo-area-use-multiline-p and max-mini-window-height,
> both of which predate Eglot.

So there is a workaround for it anyway, thanks for the reminder.

> Of course I think the current behaviour is better.  But it's also different so
> I don't think we should backport that particular one.  Even if so far the
> only feedback we have had has been positive, it could well be that some
> people _liked_ the half-the-window-height thing (after all their customization
> options reflected that wish, even if by default).
>
> And by the way, not really half-the-window.  I used this for a long time
> without being much bothered by it.

I guess it depends on the number of overloads for the function around point.

> > 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.
>
> It was reported a long time ago.  By you and others.  But there wasn't
> the means -- or rather the energy from my part -- to fix it.  I couldn't
> just have truncated that information.  So I enhanced ElDoc instead with
> the :echo option.

Aha, so the :echo thingy made it possible. Gotcha.