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: Sat, 15 Apr 2023 11:24:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> > So you don't recommend that users who want a stable Eglot upgrade to
>> > 1.14?
>> Depends on how "stable" they want it and how badly they want new
>> features.
> You are dodging the question, which is unfortunate.  

I'm not.  I don't have an answer.  I can't have one.  It depends on the
user's wishes.

Case 1: You use Emacs in a debian server VM you're setting up, perhaps
in a remote location, perhaps shared with other users.  Just 'sudo apt
install emacs clangd'.  No .emacs file at all and you can go edit little
C programs conveniently and quickly.  Then I recommend Eglot 1.12.29
bundled with emacs 29.

Case 2: For your "daily driver" home system, I recommend `M-x
package-install RET eglot' (at least I used to, that is ) since that
will bring you the latest nice features tested to a good degree, but not
as well tested as 1.12.29.

> important question, much more general and important than this
> tempest-in-a-teapot issue we are discussing here.  

If I were to use your rhetoric, I would say you are "shifting" the
question.  I've never had real problems about this.  But if you want to
"revisit this question seriously", I'll be there, of course.

> We will need to revisit this question seriously if we ever succeed in
> removing 'core'
...
> Based on your answer, it sounds like Eglot users are on their own in
> this aspect: they have no real guidance from you which version is
> currently considered "stable".

They have the NEWS file, the bug tracker database, and my best efforts.
I told you how I make releases.  I want them to be stable, but there is
no official pretest.  "Guidance"?  Are the two cases above I gave
guidance?  Just present some actual case and I'll give you my
recommendation.  Else it's like coming to a doctor and asking about
taking a drug: the doctor probably going to ask you questions.

>> But if a colleague goes to their workstation and shows them
>> M-x package-install RET very-fancy-nice-thing or sends them a
>> super-fancy init.el they will take it no problem, and buy you
>> coffee and rave about it. I can't be the only one who has
>> experienced this :-)
>
> I have no doubt there are such cases.  But I very much doubt they are
> the majority.  

I don't, whole '.emacs' get shared like crazy.  That's the number one
method of "getting a configuration". People see other's Emacs in
screenshots or over the shoulder and ask to see their init file.  Not
just Emacs of course, any util.  Then they copy over bits they think are
cool/useful.  What you think they won't copy "use-package" forms??

People don't read NEWS and they don't read the manual.  Most Emacs users
I knew don't even know NEWS exists, what with that strange all caps
name.  They probably think it's some major mode for journalists.

> To reiterate: I think each release of Emacs should ship with the
> latest stable version of each core package.  If this is the case, the
> need to upgrade core packages via package.el is not very important for
> the majority of our users who prefer to use a stable Emacs.  Thus, the
> arguments you present emphasize the needs of the minority, and
> therefore I don't consider them strong enough to invalidate the
> compromise solution to which we are converging.

Sorry, but IMO you come up with very complicated logic and premises
about stability just to arrive at where you want to arrive.

A simple, readily verifiable fact remains.  M-x package-install RET
eglot in Emacs 29 will bring you a older version than in Emacs 28.  If
not today, tomorrow, eventually it will.  And that's just bad in my
opinion.  And it will become worse.

If, in your opinion, this is somehow a good or indifferent thing, we can
stop the whole discussion right here.

Again: if you think it's a _good thing_ that, in Emacs 29

  (use-package eglot :ensure t) 

or

  (package-install 'eglot)

or 

  M-x package-install RET eglot

produces an older version of Eglot than the very same form in Emacs 26,
27 and 28, please do say so ASAP.

I was under the impression that you didn't prefer that, but I'm not sure
anymore after reading your complex last paragraph.

>> I think it's imperative to _allow_ -- as you say -- and also and
>> to _make easy_.
>
> "C-u M-x package-install" is easy enough.
>
>> More importantly, and to the point, to _make it as easy as it was in
>> Emacs 26, 27 and 28_.
>
> That's an impractical request, one that most probably prefers Eglot
> users (and only part of them at that) to those of other core packages.
> We must think about all the users, not just users of Eglot.  The price
> of adaptation to the fact that Eglot is now a core package, while it
> is not nil, is not high.  So once again, this solution is IMO a
> reasonable compromise, given the constraints.

It's _not_ impractical.  There doesn't have to be a "compromise
solution" at all.  There _can_ be a win-win solution (presuming I even
understand what counts as a win to you in this issue).

I just gave Philip a 7 line patch, my fourth in this discussion, that
does exactly I think answers all of your objections regarding
risk/stability.  Much simpler than any patch so far by _any_ measure.
Lines of code, cyclomatic complexity, number of user options, NEWS
changes.  Will you look at it?

João





reply via email to

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