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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62720 <at> debbugs.gnu.org, rpluim <at> gmail.com, philipk <at> posteo.net, monnier <at> iro.umontreal.ca, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 19 Apr 2023 00:06:01 +0300

On 18/04/2023 23:56, João Távora wrote:
> On Tue, Apr 18, 2023 at 9:38 PM Dmitry Gutov <dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.