GNU bug report logs -
#62720
29.0.60; Not easy at all to upgrade :core packages like Eglot
Previous Next
Reported by: João Távora <joaotavora <at> gmail.com>
Date: Fri, 7 Apr 2023 22:11:01 UTC
Severity: normal
Found in version 29.0.60
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
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
This bug report was last modified 2 years and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.