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

Previous Next

Full log

Message #550 received at 62720 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62720 <at> debbugs.gnu.org, rpluim <at> gmail.com, philipk <at> posteo.net,
 Dmitry Gutov <dmitry <at> gutov.dev>, monnier <at> iro.umontreal.ca, larsi <at> gnus.org
Subject: Re: 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 <at> gnu.org> wrote:
>
> > Date: Wed, 19 Apr 2023 00:20:21 +0300
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, philipk <at> posteo.net,
> >  62720 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
> > From: Dmitry Gutov <dmitry <at> 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

Previous Next

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