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

[João Távora]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

>   yield something that users might consider "inferior" feature-wise when
>   𝒫=eglot.  
> A bit of a bummer, but not a deal-breaker IMO; 

It's not the end of the world.  But certainly not good, especially if
those users have just upgraded to Emacs 29 on some new machine and
ported over their Emacs 28 config.  It could even break.  In fact
eventually it will simply break, if Eglot 1.16 adds, say, some
eglot-fancy-eldoc-function and the config has

  (package-install 'eglot)
  (add-hook 'eldoc-documentation-functions 'eglot-fancy-eldoc-function)

This will break sooner or later, and bizzarely so, IMO.

Just as a data point, I got a lot of confused users just because of
bug#62576 and the missing "project-name" function.  And, mind, you
there, the simplest of workarounds, restarting Emacs fixes the issue.
But it still confused a load of users so eventually I tooks steps to
avoid it.

Just see
https://github.com/joaotavora/eglot/search?q=project-name&type=discussions

>   Sorry for butting in and adding more words to this lengthy discussion;
>   just thought that hearing the perspective from one random user might
>   help.  

No problem.  I always like reading your feedback :-)

Let's see where the tip of this discussion is heading.  Philip proposes:

> > - User option to enable upgrading built-in packages
> > - Prefix argument to enable upgrading built-in packages
> > - Always upgrade built-in packages

And Eli replies:

> The first two on emacs-29, the last one on master 

Now, this means that things like (use-package eglot :ensure t) in Emacs
26, 27 and 28 will rev up Eglot to the very latest, Emacs 29 will stay at
1.12.29 and Emacs 30, 31, 32 again to the very latest.

This is almost the mathematical definition of instability.  And the
amplitude of the version cliff will just keep growing.  I just don't
think it's a good thing, but if Eli and you think it is, that's
perfectly legitimate.

The key thing here is that there was a package hitherto with given
 update semantics.  That package wasn't in core and now is.  It's a clear
clash of update semantics, and noone (including me) was able to foresee
it.

I do appreciate all the other arguments for stability.  Because of that
I proposed a very simple patch that addresses everyone's concern but
unfortunately I don't think is going anywhere -- who knows for what
reason.  Even though Philip, Dmitry and I himself think it is the
cleanest solution for emacs 29.  See the patch here: it's 6-7 lines of
code.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#467

>   between Eli & Philip re. changing package-install or package-update
>   makes me unsure what "U x" will actually do with eglot in Emacs 29, so
>   my previous parenthesized digression might be moot.

Alas U x in the package menu _also_ doesn't upgrade Eglot.  And neither
does M-x package-update-all.  I don't see any plans for doing so.

João