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 21:12, Philip Kaludercic wrote:
>> 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---
>
> But that's the thing: upgrading to a recent version of Eglot is not
> only for the more advanced user. Those can easily go the 'M-x
> list-packages C-s eglot i x' route.
>
> It is those who do the minimum customization and/or are just
> introduced to Emacs, can miss out with more likelihood the longer the
> steps to upgrade Eglot are going to be.

Perhaps, but I don't think that eglot-update/upgrade is a necessary
improvement from that perspective.

> The newest version of Eglot is not just the latest shiny, it's also
> the most recent mapping of modes to language servers, for example. Or
> mapping of Emacs features to LSP capabilities. 

I am afraid I don't get what you mean here?  Could you give an example?

>                                                And Emacs 29 will
> continue to be installed and used 3-5-7 years after its release, where
> some of this stuff will definitely get outdated. If we fixed
> package-upgrade, that could be easy enough, but 'M-x eglot-upgrade'
> can be a comparable alternative.

What do you think about the approach of adding package.el to ELPA, and
then being able to fix the issue of package-upgrade/install that way?

On a related-topic: Shouldn't major modes modify `eglot-server-programs'
instead of centralising all the information in eglot.el?  If that were
the common practice, then it would be a lot easier to propagate
new information about the best language servers to use.

>> Just thinking about introducing a command that we right-now plan to
>> deprecate by the next release is not something I look forward to.
>
> It would probably be deprecated only several major versions later.

Not to my knowledge?

>> 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.
>
> I don't know if it's "central": according to the docs, (use-package
> eglot :ensure t) is only meant to ensure that Eglot is
> installed. Whether that means the very latest version at the time the
> configuration is first run, or not, seems a matter of opinion.

In that case we agree.  I believe João held a different opinion, but as
I was not able to follow the discussion over the last week in detail I
might have missed something.