bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Tue, 18 Apr 2023 21:56:43 +0100

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.

And I repeat it didn't (and doesn't) have to be like this for Eglot and
Emacs 29.  It could have been a minor decision, not a "major" one.

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

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

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.

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

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]