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 10:06 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> 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.

Hence, more unstable.  There aren't watertight borders here.  These users
in the "third-party" community are using nothing but Emacs and GNU ELPA
Eglot, those are the users that we're hurting while to protect the
non Eglot users.  But why on earth can't we protect the non-Eglot users and
not screw the Eglot users.  We can, with a simpler change.

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

It's 7 lines of code.  Elisp should be trivial to read.  Eli read
much more complicated code in this thread.

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

I'm using C++ ;-)

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

Right, which is also the reason it makes even _less_ sense to bring Eglot
1.15 into Emacs 29 _without_ ElDoc (I hope that plan is now completely off
the table).

João