[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: |
Wed, 19 Apr 2023 14:04:10 +0100 |
On Wed, Apr 19, 2023 at 1:05 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Wed, 19 Apr 2023 00:20:21 +0300
> > Cc: Eli Zaretskii <eliz@gnu.org>, rpluim@gmail.com, philipk@posteo.net,
> > 62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > On 19/04/2023 00:15, João Távora wrote:
> > >> 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).
> >
> > Eh, sure.
>
> It isn't my call in this case, but FWIW: I still have no idea why
> wouldn't we want Eglot 1.14 or 1.15 to be in Emacs 29.1. I didn't
> hear any serious argument against doing that; every reason that was
> raised was almost immediately explained away as not being a hard
> limitation.
>
> And mind you: Emacs 29.1 will not be released tomorrow or the day
> after. We still have at least several weeks till then, with at least
> one more pretest. So the decision whether to import a newer Eglot
> into the release branch doesn't have to be today. However, the
> argument against updating Eglot on the release branch, such as they
> were, are of some vaguely "fundamental" nature, so I'm not sure a few
> more weeks of time will change the decision. No one said something
> like "if Emacs 29.1 were to be released in NN weeks or more, it would
> be okay to update Eglot on the release branch." But then I already
> admitted to not understanding those reasons, so maybe I'm missing
> something here.
>
> So there you are.
Eli, do you want Eglot 1.14 (or 1.15, or 1.16 or whatever version
is the latest Eglot release "several weeks" from now) to be in Emacs 29?
>From your writings, I'm assuming you do. Let's call that version Eglot
1.1x with x > 14. If we did that, we would have two options:
1. Bundle Eglot 1.1x with Emacs 29 and all its up-to-date dependencies, so
that, right at the moment of the Emacs 29 release, Eglot would function
exactly the same on Emacs 28 + package-install.
2. Bundle a "Frankenglot" with Emacs 29 that has all the
lisp/progmodes/eglot.el code of the future Eglot version, advertises
itself as Eglot 1.1x, probably doesn't break, but does _not_ provide
the same experience as Emacs 28 + package-install
Both options are bad, IMO, but 2 is worse.
The first reason that both options are bad is that you're discarding
whatever value the pretest phase brings to the stability of Eglot's code.
Eglot, being a part of Emacs the Emacs code base, benefits from the same
testing all its code does. You're discarding that value, and I think
it's bad, because the pretest is supposedly there for a good reason. A bug in
Eglot 1.1x will just escape us and there's no time to fix it.
The second reason only applies to option 2. It would completely confuse
users. A user running Emacs 28 would see a much better 1.1x than
the 1.1x bundled in Emacs 29. Her configuration for Eglot 1.1x
could simply break in 1.1x. Eglot 1.1x was never designed to be
run in such a hampered environment.
They are "fundamental" reasons indeed. Are they now less vague
and more concrete?
João
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, (continued)
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/16
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/16
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/17
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/18
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/18
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/18
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/18
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/18
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/18
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot,
João Távora <=
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/19
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/19