Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720)

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> [ I think everything has already been said in this discussion, so let me
> try to answer two-in-one mails to minimize chatter. ]
>
> PK> experiences.  I have a hunch that João as the maintainer of Eglot is
> PK> over-exposed to people who are interested in having the absolutely
> PK> newest version so they can make use of the absolutely newest
> PK> features,
>
> I don't know what that means.  I am exposed to the users I am exposed
> to, and there seem to be a lot of them.  A lot of reports and
> conversations over here and over at GitHub.  I spend my time with them,
> very often having to guess things.  If I can at least minimize the time
> wasted agreeing on what Eglot version is being used or how to get the
> newest bugfix/feature, I do want that.

My point is that I am guessing the average user you interact with is
either having issues or is actively interested in Eglot.  I suspect (and
it is my experience) the average user, just like the average Emacs user,
does not really think about the specific version they are running.

> PK> I have in my init.el is a lot:
> PK> eldoc-echo-area-use-multiline-p nil
>
> If you upgrade Eglot, you probably won't need this customization ;-)

How come, is this not related to eldoc?

> DG> some of this stuff will definitely get outdated. If we fixed
> DG> package-upgrade, that could be easy enough, but 'M-x eglot-upgrade'
> DG> can be a comparable alternative.
> PK>> Just thinking about introducing a command that we right-now plan to
> PK>> deprecate by the next release is not something I look forward to.
> DG> It would probably be deprecated only several major versions later.
>
> Dmitry is right.
>
> An interesting direction would be to fix package-upgrade in Emacs 29 &
> make package.el a self-updating :core package itself.  But the former
> has been ruled out and the latter is also looking murky.  Are there
> other more complicated ways to achieve this?  Of course, and
> list-packages was the first workaround listed by me when I opened
> bug#62720.  But the menu is fraught with its own problems (slow,
> complicated and sometimes downright broken by some accounts).

Broken?  If that is the case, the issue should be addressed, but the
only issue I know of is that the package status is occasionally
incorrect, but that does not affect the packages itself.

> eglot-update _not_ the prettiest option, but it's the best _possible_
> option which guarantees consistency across Emacs versions.  I've
> exhausted my attempts to steer this discussion in other directions.

In my eyes it is not only not-pretty, but unnecessary (considering that
list-packages does work and does so consistently over versions) and
confuse the average user, when the command is eventually deprecated, but
low-quality web forums recommend using it in their archives.

> So eglot-update it is.  I buy the consistency argument, I do, but there
> are plenty of <package>-version and <package>-bug too in the Emacs tree
> There is even tramp-recompile-elpa.  None of this is deprecated.  Which
> just means maintainters need things to work foremost before wanting them
> to be pretty.

It should be deprecated though, and I don't think that these patterns
should be encouraged or added.

> João