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

[Philip Kaludercic <philipk@posteo.net>]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 28/04/2023 17:25, Philip Kaludercic wrote:
>> Eli Zaretskii<eliz@gnu.org>  writes:
>> 
>>>> Date: Fri, 28 Apr 2023 02:52:56 +0300
>>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>>
>>>> Hi!
>>>>
>>>> On 28/04/2023 02:39, João Távora wrote:
>>>>>       * lisp/progmodes/eglot.el (eglot-update): New command.
>>>> Should it be called eglot-upgrade now as well?
>>> No, it should be removed.
>> 1+
>
> This doesn't sound very constructive at this point.

It is difficult to be constructive here.  I believe that the long-term
complications/confusion of introducing this kind of a command instead of
instructing users on Emacs 29 to update a package like Eglot manually is
not worth it, while others do.  These matters are difficult to quantify,
so we cannot reach a consensus by pointing to some objective reality,
and instead of have to fall back on personal impressions and
experiences.  I have a hunch that João as the maintainer of Eglot is
over-exposed to people who are interested in having the absolutely
newest version so they can make use of the absolutely newest features,
while most people I know, personally or online, that make use of Eglot
barley bother to configure it at all (I consider that to be one of the
major setting points for the package, btw).  Comparing other
configurations I have seen online, I actually think that what I have in
my init.el is a lot:

--8<---------------cut here---------------start------------->8---
(setup eglot
  (setopt eglot-autoshutdown t
          eglot-extend-to-xref t
          eldoc-echo-area-use-multiline-p nil
          eldoc-idle-delay 0.1)
  (:bind "C-c a" #'eglot-code-actions
         "C-c z" #'eglot-format
         "C-c r" #'eglot-rename)
  (:unbind [remap display-local-help]))
--8<---------------cut here---------------end--------------->8---

Just thinking about introducing a command that we right-now plan to
deprecate by the next release is not something I look forward to.  Even
just promoting the concept of having a package-specific upgrade command
is something I am a afraid of (it took for ages for third-party packages
to stop adding pointless `foo-version' commands).  And I might have
missed something here, but none of this would tackle the "central" issue
of use-package not installing the newest version of a package if the
package is already built-in, but hasn't yet been installed before.  As
mentioned above: If we want to tell users to install packages using a
custom command, they might as well use M-x list-packages and select the
package from ELPA that way?