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

["João Távora" <joaotavora@gmail.com>]

On Wed, Apr 19, 2023 at 2:35 PM Eli Zaretskii <eliz@gnu.org> wrote:

> What I want in Emacs 29.1 (and any future release of Emacs) is the
> latest version of Eglot that you, as Eglot developer, consider stable
> enough to recommend to users of a stable Emacs.  Which version is that
> is your decision.  But to make sense to me, the decision you make
> should be consistent: if a version X.Y of Eglot is "stable enough" for
> you to recommend that users of Emacs 29.n upgrade to it, then that
> version X.Y can be part of Emacs 29.n.  (Of course, if you decided
> that X.Y is stable enough _after_ Emacs 29.n was released, then X.Y
> will be able to become part of Emacs only in Emacs 29.n+1 and later.)

OK. Then I will tell you that "stable enough", for, me means "as stable
as possible", because I like things to be as stable as possible.
And, to me (and I would think to most people), the most stable
version of a program is the one which has seen the most testing. So,
I see no reason to give Eglot a shorter pretest period than the
rest of Emacs gets.  Thus Eglot 1.12.29 it is.

> I hope I clarified my position in this regard.

OK, it seems you're giving the call to me.  Then I hope I've also
clarified my decision and the criteria I used in reaching it.

> > 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.
>
> That is probably not acceptable, although I'd need to know exactly
> which versions of what other packages need to be imported into the
> emacs-29 branch, to give a definitive answer.

I could teach you how to figure that out (it's very simple), but
since I don't want this either, and you just gave the call to me,
there's probably no point.

> > 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.
>
> I don't see why option 2 would be bad, let alone worse.  See below.
>
> > 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 itself isn't my problem.  My problem is the other packages that
> upgrading Eglot, per option 1 above, will require to update: those
> other packages usually affect much more than just Eglot, and therefore
> bringing their potentially less stable code into emacs-29 might break
> much more than just Eglot.

Yes, as I said option 1 is bad.  Option 2 is worse, but 1 is pretty
bad too, partly for the reasons you state (yes you're totally right
"it's much more than Eglot").

> > 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.
>
> Please leave this consideration to me, it is exactly the kind of
> judgment call I make every several days when someone asks whether a
> particular change is OK for the release branch.  And in the case of
> Eglot I already said that IMO we should include in Emacs 29.1 the
> latest stable version of Eglot, thus my decision about that was
> already made in favor of upgrading Eglot on emacs-29.  But I won't
> insist if you are uncomfortable with that.

There is no one "stable".  You yourself are talking about stability
gradation.   Eglot 1.12.29 is "stablest".  Eglot 1.14 is "stable". Eglot
in master has recently gone two days with a semi-serious live bug (now
fixed) Let's call it "unstable" anyway.  Before I release 1.15, I will
try to make
sure it is as stable as 1.14 (or more).

By the way, the ElDoc change about the non-blinking is "safe for
the release branch" IMHO.  Just in case you didn't get my opinion
on that part of ElDoc of which I am the author and the maintainer
since 2018.

> > 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.
>
> No, users of Emacs 28 who installed the latest stable Eglot from ELPA
> should see almost the same version of Eglot as users of Emacs 29.1 if
> that will come with the same stable Eglot.  Unless you intend to
> somehow degenerate important parts of Eglot in what you call
> "Frankenglot", whatever that means.

Frankenglot 1.1x is just Eglot without the resources that 1.1x would
have in Emacs 28.  Don't you understand?  The "good" Eglot experience
requires things that are not in lisp/progmodes/eglot.el.  It requires,
for example, :echo support in ElDoc's eldoc-documentation-functions
so that echo areas aren't flooded by some LSP servers.
eglot.el can function without it, but users would be surprised.  They would
ask: hey didn't you fix this echo area flooding, back in Eglot 1.14???
And I would have to explain: this is not really Eglot 1.1x, this is
Frankenglot 1.1x:  the content of the eglot.el file is the same but
it's missing a lot of stuff.  And then I wouldn't even know how to
teach them to upgrade.

In so many software packages I know outside of Emacs, bugs and
features are fixed and added just by bumping a dependency.  Surely
you must have seen this, too.

> My interpretation of option 2 is that we get a newer Eglot (1.14 or
> 1.15, whichever you decide is stable enough) with various minor
> fallbacks intended to work around the fact that dependency packages
> are not necessarily at their versions for which Eglot 1.14/1.15 was
> designed to work, if the versions of those dependencies in Emacs 29.1
> are older.

Why put ourselves (mostly myself) through these chores??  Just so that
two weeks later after whatever Emacs 29 is officially released a more
recent,  "stable"  version is already available? And pay the price of
discarding the value of the pretest period?  Just because Eglot is now
much harder to  upgrade?  Then just make it easy to upgrade: it's in your
control.

There there are 0 downsides, as far as I can tell.  As far as anyone
who has commented that patch can tell.   I've seen 0 contestation
of the patch I proposed before, which I've grown almost tired of
linking to.  That patch was engineered to answer precisely your
objections to previous patches.  It was engineered to make _you_
happy and make me happy, and make Eglot users happy.  And you're
ignoring it.

 That is, 1.14/1.15 without the mandatory requirement o
> upgrade any other package already in Emacs.  If that is not what you
> mean, then perhaps consider this as option 3

No, you're just describing option 2, as far as I can see.
But probably no "various minor fallbacks" would be needed, because
I am careful with the interfaces.


-- 
João Távora