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

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

[Dmitry Gutov]

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?

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

[João Távora]

On Fri, Apr 28, 2023 at 12:53 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> 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 objection, don't feel strongly about it.  If you want to
change it, go ahead, but remember to change the manual as
well.

João

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

[Dmitry Gutov]

On 28/04/2023 03:35, João Távora wrote:
> On Fri, Apr 28, 2023 at 12:53 AM Dmitry Gutov<dmitry@gutov.dev>  wrote:
>> 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 objection, don't feel strongly about it.  If you want to
> change it, go ahead, but remember to change the manual as
> well.

You're okay with not changing it as well? Keeping its name different 
from package-upgrade?

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

[Dmitry Gutov]

On 28/04/2023 03:35, João Távora wrote:
> On Fri, Apr 28, 2023 at 12:53 AM Dmitry Gutov<dmitry@gutov.dev>  wrote:
>> 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 objection, don't feel strongly about it.  If you want to
> change it, go ahead, but remember to change the manual as
> well.

Ok, I did the rename.

Two more things:

- Commit 44ebd9cbd56 also removed the call to (eldoc) from the end of 
eglot-completion-at-point which has been there for a few years. Was that 
intentional? Didn't look like it.

- Consider the issue that I brought up in 
https://debbugs.gnu.org/62720#715 regarding (cadr (assoc 'eglot 
package-archive-contents)). I'm not sure there's even a guarantee that 
the available versions are sorted, but even if they are obeying 
package-archive-priorities seems like a good idea. Though I can 
understand if it's not your first priority in this command.

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

[João Távora]

On Wed, May 3, 2023 at 11:48 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 28/04/2023 03:35, João Távora wrote:
> > On Fri, Apr 28, 2023 at 12:53 AM Dmitry Gutov<dmitry@gutov.dev>  wrote:
> >> 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 objection, don't feel strongly about it.  If you want to
> > change it, go ahead, but remember to change the manual as
> > well.
>
> Ok, I did the rename.

Hmmm, unfortunate.  I thought you had abandoned the idea,
as you didn't reply to that part specifically.  The problem
is that Eglot 1.15, released in the meantime, now has
eglot-update.  So I think we should rename it back in Emacs 29,
sorry. Either that or release Eglot 1.16 asap.

> Two more things:
>
> - Commit 44ebd9cbd56 also removed the call to (eldoc) from the end of
> eglot-completion-at-point which has been there for a few years. Was that
> intentional? Didn't look like it.

Not intentional no.  Well, at least not for that commit.
Not pretty, but I wouldn't worry about it.

> - Consider the issue that I brought up in
> https://debbugs.gnu.org/62720#715 regarding (cadr (assoc 'eglot
> package-archive-contents)). I'm not sure there's even a guarantee that
> the available versions are sorted, but even if they are obeying
> package-archive-priorities seems like a good idea. Though I can
> understand if it's not your first priority in this command.

Is this a problem that can affect the Eglot package
specifically?  In which conditions?

João

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

[Dmitry Gutov]

On 04/05/2023 02:31, João Távora wrote:
> On Wed, May 3, 2023 at 11:48 PM Dmitry Gutov<dmitry@gutov.dev>  wrote:
>> On 28/04/2023 03:35, João Távora wrote:
>>> On Fri, Apr 28, 2023 at 12:53 AM Dmitry Gutov<dmitry@gutov.dev>   wrote:
>>>> 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 objection, don't feel strongly about it.  If you want to
>>> change it, go ahead, but remember to change the manual as
>>> well.
>> Ok, I did the rename.
> Hmmm, unfortunate.  I thought you had abandoned the idea,
> as you didn't reply to that part specifically.

I did reply, with a question.

> The problem
> is that Eglot 1.15, released in the meantime, now has
> eglot-update.  So I think we should rename it back in Emacs 29,
> sorry. Either that or release Eglot 1.16 asap.

I figured it wouldn't be required of me to fix the consistency of 
function naming in your package. But nobody else did it.

I don't think it's really important to keep backward compatibility 
between Eglot 1.15 and 1.16 (as we've noted before, only the latest 
version remains). And just like there's likely no callers of 
package-update out-of-tree, I don't imagine there's going to be a lot of 
Lisp code calling eglot-update as well.

Up to you either way.

>> Two more things:
>>
>> - Commit 44ebd9cbd56 also removed the call to (eldoc) from the end of
>> eglot-completion-at-point which has been there for a few years. Was that
>> intentional? Didn't look like it.
> Not intentional no.  Well, at least not for that commit.
> Not pretty, but I wouldn't worry about it.

So it's not a breakage? Okay then.

>> - Consider the issue that I brought up in
>> https://debbugs.gnu.org/62720#715  regarding (cadr (assoc 'eglot
>> package-archive-contents)). I'm not sure there's even a guarantee that
>> the available versions are sorted, but even if they are obeying
>> package-archive-priorities seems like a good idea. Though I can
>> understand if it's not your first priority in this command.
> Is this a problem that can affect the Eglot package
> specifically?  In which conditions?

The user customizes priorities for GNU ELPA and GNU-devel, and 'M-x 
eglot-upgrade' upgrades to a version from the archive with lower 
priority. Something like that.

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

[João Távora]

On Thu, May 4, 2023 at 12:39 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 04/05/2023 02:31, João Távora wrote:
> > On Wed, May 3, 2023 at 11:48 PM Dmitry Gutov<dmitry@gutov.dev>  wrote:
> >> On 28/04/2023 03:35, João Távora wrote:
> >>> On Fri, Apr 28, 2023 at 12:53 AM Dmitry Gutov<dmitry@gutov.dev>   wrote:
> >>>> 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 objection, don't feel strongly about it.  If you want to
> >>> change it, go ahead, but remember to change the manual as
> >>> well.
> >> Ok, I did the rename.
> > Hmmm, unfortunate.  I thought you had abandoned the idea,
> > as you didn't reply to that part specifically.
>
> I did reply, with a question.

Right, but I had said "I don't feel strongly about it",
meaning I don't care either way.  So i didn't reply because
I though I would be repeating myself.

Anyway, I would rather not have people that have already gotten 1.15 and
using it (not many) seeing eglot-update change to eglot-upgrade.
By 1.20 noone will remember, but I think we should at least add a
compatibility alias (eglot-upgrade being the advertised one, and keep
eglot-update for 3/4 versions).

> Up to you either way.

Please add the compatibility alias, if you can.

> >> Two more things:
> >>
> >> - Commit 44ebd9cbd56 also removed the call to (eldoc) from the end of
> >> eglot-completion-at-point which has been there for a few years. Was that
> >> intentional? Didn't look like it.
> > Not intentional no.  Well, at least not for that commit.
> > Not pretty, but I wouldn't worry about it.
>
> So it's not a breakage? Okay then.

No, it was actually intended (not for that commit of course).

>
> >> - Consider the issue that I brought up in
> >> https://debbugs.gnu.org/62720#715  regarding (cadr (assoc 'eglot
> >> package-archive-contents)). I'm not sure there's even a guarantee that
> >> the available versions are sorted, but even if they are obeying
> >> package-archive-priorities seems like a good idea. Though I can
> >> understand if it's not your first priority in this command.
> > Is this a problem that can affect the Eglot package
> > specifically?  In which conditions?
>
> The user customizes priorities for GNU ELPA and GNU-devel, and 'M-x
> eglot-upgrade' upgrades to a version from the archive with lower
> priority. Something like that.

Too late to think about what the right thing to do is.  What I
think i'll do eventually is add a confirmation prompt for
interactive calls to eglot-update.

João

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

[Dmitry]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

On Thu, May 4, 2023, at 3:50 AM, João Távora wrote:
> Anyway, I would rather not have people that have already gotten 1.15 and
> using it (not many) seeing eglot-update change to eglot-upgrade.
> By 1.20 noone will remember, but I think we should at least add a
> compatibility alias (eglot-upgrade being the advertised one, and keep
> eglot-update for 3/4 versions).
That would make the situation even more of a mess, wouldn't it? Unless you intend to drop the alias after a couple of Eglot's releases. But that wouldn't be possible because both names would have appeared in Emacs 29.
> > Up to you either way.
> 
> Please add the compatibility alias, if you can.
> 
> > >> Two more things:
> > >>
> > >> - Commit 44ebd9cbd56 also removed the call to (eldoc) from the end of
> > >> eglot-completion-at-point which has been there for a few years. Was that
> > >> intentional? Didn't look like it.
> > > Not intentional no.  Well, at least not for that commit.
> > > Not pretty, but I wouldn't worry about it.
> >
> > So it's not a breakage? Okay then.
> 
> No, it was actually intended (not for that commit of course).
As long as it was intended for Emacs 29.
> >
> > >> - Consider the issue that I brought up in
> > >> https://debbugs.gnu.org/62720#715  regarding (cadr (assoc 'eglot
> > >> package-archive-contents)). I'm not sure there's even a guarantee that
> > >> the available versions are sorted, but even if they are obeying
> > >> package-archive-priorities seems like a good idea. Though I can
> > >> understand if it's not your first priority in this command.
> > > Is this a problem that can affect the Eglot package
> > > specifically?  In which conditions?
> >
> > The user customizes priorities for GNU ELPA and GNU-devel, and 'M-x
> > eglot-upgrade' upgrades to a version from the archive with lower
> > priority. Something like that.
> 
> Too late to think about what the right thing to do is.  What I
> think i'll do eventually is add a confirmation prompt for
> interactive calls to eglot-update.
Okay. That can work.

[-- Attachment #2: Type: text/html, Size: 3046 bytes --]

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

[João Távora]

On Thu, May 4, 2023 at 1:57 AM Dmitry <dmitry@gutov.dev> wrote:
>
> On Thu, May 4, 2023, at 3:50 AM, João Távora wrote:
>
> Anyway, I would rather not have people that have already gotten 1.15 and
> using it (not many) seeing eglot-update change to eglot-upgrade.
> By 1.20 noone will remember, but I think we should at least add a
> compatibility alias (eglot-upgrade being the advertised one, and keep
> eglot-update for 3/4 versions).
>
> That would make the situation even more of a mess, wouldn't it? Unless you intend to drop the alias after a couple of Eglot's releases. But that wouldn't be possible because both names would have appeared in Emacs 29.

Why messy?  "update" and "upgrade" and used interchangeably
anyway in speech/writing. But if it's "less messy" to revert eglot-update
then no problem.

> > Up to you either way.
>
> Please add the compatibility alias, if you can.
>
> > >> Two more things:
> > >>
> > >> - Commit 44ebd9cbd56 also removed the call to (eldoc) from the end of
> > >> eglot-completion-at-point which has been there for a few years. Was that
> > >> intentional? Didn't look like it.
> > > Not intentional no.  Well, at least not for that commit.
> > > Not pretty, but I wouldn't worry about it.
> >
> > So it's not a breakage? Okay then.
>
> No, it was actually intended (not for that commit of course).
>
> As long as it was intended for Emacs 29.

There's no harm in having it in Emacs 29 (that's where
I tested it).

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

[Dmitry Gutov]

On 04/05/2023 04:09, João Távora wrote:
> On Thu, May 4, 2023 at 1:57 AM Dmitry<dmitry@gutov.dev>  wrote:
>> On Thu, May 4, 2023, at 3:50 AM, João Távora wrote:
>>
>> Anyway, I would rather not have people that have already gotten 1.15 and
>> using it (not many) seeing eglot-update change to eglot-upgrade.
>> By 1.20 noone will remember, but I think we should at least add a
>> compatibility alias (eglot-upgrade being the advertised one, and keep
>> eglot-update for 3/4 versions).
>>
>> That would make the situation even more of a mess, wouldn't it? Unless you intend to drop the alias after a couple of Eglot's releases. But that wouldn't be possible because both names would have appeared in Emacs 29.
> Why messy?  "update" and "upgrade" and used interchangeably
> anyway in speech/writing. But if it's "less messy" to revert eglot-update
> then no problem.
> 

Here's an idea: only add the alias on master, to be in the next ELPA 
release of Eglot. Then you could phase it out a couple of releases 
later, before Emacs 30 is done.

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

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

>>> That would make the situation even more of a mess, wouldn't it?
>>> Unless you intend to drop the alias after a couple of Eglot's
>>> releases. But that wouldn't be possible because both names would
>>> have appeared in Emacs 29.
>> Why messy?  "update" and "upgrade" and used interchangeably
>> anyway in speech/writing. But if it's "less messy" to revert eglot-update
>> then no problem.

> Here's an idea: only add the alias on master, to be in the next ELPA
> release of Eglot. Then you could phase it out a couple of releases
> later, before Emacs 30 is done.

I added the obsolete compat alias in Emacs 29 (and soon master) in the
end.  I'd rather not have anyone switching back and forth from Emacs
version confused about some command works in some version and not
others.  Can't really foresee any problems.  Also renamed it to
eglot-upgrade-eglot to make it more obvious.

João

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

[Dmitry Gutov]

On 05/05/2023 17:01, João Távora wrote:
> I added the obsolete compat alias in Emacs 29 (and soon master) in the
> end.  I'd rather not have anyone switching back and forth from Emacs
> version confused about some command works in some version and not
> others.

I figured the obsoletion warning would take care of any confusion.

> Can't really foresee any problems.

Just the fact that whole two versions of this command will now have to 
stay around for several years.

> Also renamed it to
> eglot-upgrade-eglot to make it more obvious.

That's okay.

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

[Eli Zaretskii]

> 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.

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

[Philip Kaludercic]

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+

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

[Dmitry Gutov]

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.

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

[Philip Kaludercic]

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?

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

[Dmitry Gutov]

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.

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. 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.

> 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.

> 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.

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

[Eli Zaretskii]

> Date: Sat, 29 Apr 2023 03:52:48 +0300
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, joaotavora@gmail.com
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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.

At the risk of sounding like a broken record: introducing a new
command for upgrading Eglot has the same problem as the original one:
users of Emacs 29 will need to use a different procedure for upgrading
Eglot than they used before.  So it doesn't solve any problems, only
introduces new ones.

It's a mistake that should be fixed while we still can.

> > 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.

It was deprecated the minute it was introduced.

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

[Dmitry]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Sat, Apr 29, 2023, at 9:45 AM, Eli Zaretskii wrote:
> > Date: Sat, 29 Apr 2023 03:52:48 +0300
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, joaotavora@gmail.com
> > From: Dmitry Gutov <dmitry@gutov.dev>
> > 
> > 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.
> 
> At the risk of sounding like a broken record: introducing a new
> command for upgrading Eglot has the same problem as the original one:
> users of Emacs 29 will need to use a different procedure for upgrading
> Eglot than they used before.
But users of Emacs 28- would be able to use it too. So at least the docs could list just one method.

[-- Attachment #2: Type: text/html, Size: 1582 bytes --]

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

[Philip Kaludercic]

Dmitry <dmitry@gutov.dev> writes:

> On Sat, Apr 29, 2023, at 9:45 AM, Eli Zaretskii wrote:
>> > Date: Sat, 29 Apr 2023 03:52:48 +0300
>> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, joaotavora@gmail.com
>> > From: Dmitry Gutov <dmitry@gutov.dev>
>> > 
>> > 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.
>> 
>> At the risk of sounding like a broken record: introducing a new
>> command for upgrading Eglot has the same problem as the original one:
>> users of Emacs 29 will need to use a different procedure for upgrading
>> Eglot than they used before.
> But users of Emacs 28- would be able to use it too. So at least the docs could list just one method.

But they don't need it, because package-install does the right thing to
begin with?

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

[Dmitry]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]



On Sat, Apr 29, 2023, at 1:13 PM, Philip Kaludercic wrote:
> Dmitry <dmitry@gutov.dev> writes:
> 
> > On Sat, Apr 29, 2023, at 9:45 AM, Eli Zaretskii wrote:
> >> > Date: Sat, 29 Apr 2023 03:52:48 +0300
> >> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, joaotavora@gmail.com
> >> > From: Dmitry Gutov <dmitry@gutov.dev>
> >> > 
> >> > 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.
> >> 
> >> At the risk of sounding like a broken record: introducing a new
> >> command for upgrading Eglot has the same problem as the original one:
> >> users of Emacs 29 will need to use a different procedure for upgrading
> >> Eglot than they used before.
> > But users of Emacs 28- would be able to use it too. So at least the docs could list just one method.
> 
> But they don't need it, because package-install does the right thing to
> begin with?
> 
By default, package-install indeed "does the tight thing". But it doesn't upgrade the already-installed package.

[-- Attachment #2: Type: text/html, Size: 2224 bytes --]

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

[Eli Zaretskii]

> Date: Sat, 29 Apr 2023 13:01:48 +0300
> From: Dmitry <dmitry@gutov.dev>
> Cc: "Philip Kaludercic" <philipk@posteo.net>, emacs-devel@gnu.org,
>  joaotavora@gmail.com
> 
> On Sat, Apr 29, 2023, at 9:45 AM, Eli Zaretskii wrote:
> 
>  > Date: Sat, 29 Apr 2023 03:52:48 +0300
>  > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, joaotavora@gmail.com
>  > From: Dmitry Gutov <dmitry@gutov.dev>
>  > 
>  > 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.
> 
>  At the risk of sounding like a broken record: introducing a new
>  command for upgrading Eglot has the same problem as the original one:
>  users of Emacs 29 will need to use a different procedure for upgrading
>  Eglot than they used before.
> 
> But users of Emacs 28- would be able to use it too.

Once they learn about that.  And why should they need to, when
package-install works for them?

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

[Philip Kaludercic]

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.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  joaotavora@gmail.com
> Date: Sat, 29 Apr 2023 09:08:22 +0000
> 
> 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?

We should be careful about that: it could produce bootstrap-type
problems, since package.el is itself required for fetching stuff from
ELPA.

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

[Dmitry]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Sat, Apr 29, 2023, at 12:40 PM, Eli Zaretskii wrote:
> > From: Philip Kaludercic <philipk@posteo.net>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  joaotavora@gmail.com
> > Date: Sat, 29 Apr 2023 09:08:22 +0000
> > 
> > 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?
> 
> We should be careful about that: it could produce bootstrap-type
> problems, since package.el is itself required for fetching stuff from
> ELPA.
Right. I mentioned exactly that concern in the other bug thread.

[-- Attachment #2: Type: text/html, Size: 1144 bytes --]

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

[Philip Kaludercic]

Dmitry <dmitry@gutov.dev> writes:

> On Sat, Apr 29, 2023, at 12:40 PM, Eli Zaretskii wrote:
>> > From: Philip Kaludercic <philipk@posteo.net>
>> > Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  joaotavora@gmail.com
>> > Date: Sat, 29 Apr 2023 09:08:22 +0000
>> > 
>> > 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?
>> 
>> We should be careful about that: it could produce bootstrap-type
>> problems, since package.el is itself required for fetching stuff from
>> ELPA.
>
> Right. I mentioned exactly that concern in the other bug thread.

I think it might work, but we will have to see.

(Btw, I don't think there was ever a bug report on this matter, there
was just a discussion here on emacs-devel)

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

[João Távora]

[ 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.

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 ;-)

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).

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.

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.

João

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

[Po Lu]

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.

Why are we bickering over this?  If some user has a slightly outdated
version of a given package that we distribute, it is no great loss.

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

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

[Michael Albinus]

Philip Kaludercic <philipk@posteo.net> writes:

Hi Philip,

>> 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.

I'll happily remove tramp-recompile-elpa once bug#48015 is fixed. But it
isn't (yet).

Best regards, Michael.

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

[João Távora]

Philip Kaludercic <philipk@posteo.net> writes:

> 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.

Yeah, who knows?  And who knows if all the users we don't hear from are
all three-headed fish from Neptune?  Don't think that means I should
ignore the users that face problems/want features and do make their
voices heard.

I do agree they don't think about versions, and even less what is :core
or not.  They probably just want things to work.

>> 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?

It is, but you included it in your Eglot section, did you not?  And it
was, for a long time, a way to avoid "echo area flooding" in Eglot.  So
I figured you'd be interested in knowning that that problem is largely
fixed.

> 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.

Robert Pluim reported some breakage.  And it's suspiciously slow to
start for me.

> [eglot-update] should be deprecated though

Noone disagrees with that.  Will do once there is a better alternative,
which there isn't atm.

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:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> 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.
>
> Yeah, who knows?  And who knows if all the users we don't hear from are
> all three-headed fish from Neptune?  Don't think that means I should
> ignore the users that face problems/want features and do make their
> voices heard.
>
> I do agree they don't think about versions, and even less what is :core
> or not.  They probably just want things to work.

I agree with you on that, the issue is that we have different ideas of
what that means ^^.

>>> 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?
>
> It is, but you included it in your Eglot section, did you not?  

AFAIR I just did that because I structure my configuration with
outline-minor-mode and did not want to add another section.

>                                                                 And it
> was, for a long time, a way to avoid "echo area flooding" in Eglot.  So
> I figured you'd be interested in knowning that that problem is largely
> fixed.

OK, thanks for the tip, I will take a look if things changed for me.

>> 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.
>
> Robert Pluim reported some breakage.  And it's suspiciously slow to
> start for me.

This does not appear to have been described in a bug report?  Could you
point me to the message where this happens?

>> [eglot-update] should be deprecated though
>
> Noone disagrees with that.  Will do once there is a better alternative,
> which there isn't atm.

The plan is to address this in Emacs 30, and perhaps even earlier if we
manage to add package.el to ELPA.

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

[Robert Pluim]

>>>>> On Mon, 01 May 2023 07:34:12 +0000, Philip Kaludercic <philipk@posteo.net> said:
    >> Robert Pluim reported some breakage.  And it's suspiciously slow to
    >> start for me.

    Philip> This does not appear to have been described in a bug report?  Could you
    Philip> point me to the message where this happens?

I didnʼt report a bug, because

    M-x list-packages
    U
    x
    <restart emacs> => lots of errors about wrong package version or
    missing packages
    <frantically reinstall/upgrade packages until errors are gone>

is not something that can easily be reproduced and fixed.

Although next time I upgrade packages, Iʼll save a before/after
listing to see if it offers any insight.

Robert
-- 

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

[Philip Kaludercic]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 01 May 2023 07:34:12 +0000, Philip Kaludercic <philipk@posteo.net> said:
>     >> Robert Pluim reported some breakage.  And it's suspiciously slow to
>     >> start for me.
>
>     Philip> This does not appear to have been described in a bug report?  Could you
>     Philip> point me to the message where this happens?
>
> I didnʼt report a bug, because
>
>     M-x list-packages
>     U
>     x
>     <restart emacs> => lots of errors about wrong package version or
>     missing packages
>     <frantically reinstall/upgrade packages until errors are gone>

Do you happen to recall what kind of errors these were?

> is not something that can easily be reproduced and fixed.
>
> Although next time I upgrade packages, Iʼll save a before/after
> listing to see if it offers any insight.

That would be nice, thanks!

> Robert

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

[Robert Pluim]

>>>>> On Fri, 05 May 2023 05:13:08 +0000, Philip Kaludercic <philipk@posteo.net> said:

    Philip> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Mon, 01 May 2023 07:34:12 +0000, Philip Kaludercic <philipk@posteo.net> said:
    >> >> Robert Pluim reported some breakage.  And it's suspiciously slow to
    >> >> start for me.
    >> 
    Philip> This does not appear to have been described in a bug report?  Could you
    Philip> point me to the message where this happens?
    >> 
    >> I didnʼt report a bug, because
    >> 
    >> M-x list-packages
    >> U
    >> x
    >> <restart emacs> => lots of errors about wrong package version or
    >> missing packages
    >> <frantically reinstall/upgrade packages until errors are gone>

    Philip> Do you happen to recall what kind of errors these were?

It was either a `require' in my init file failing because the package
wasnʼt installed, or a package complaining that its dependencies
didnʼt exist (vague, I know)

    >> is not something that can easily be reproduced and fixed.
    >> 
    >> Although next time I upgrade packages, Iʼll save a before/after
    >> listing to see if it offers any insight.

    Philip> That would be nice, thanks!

My latest upgrade went fine. Letʼs put it down to old packages having
out-of-date dependencies :-)

Robert
-- 

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

[João Távora]

On Mon, May 1, 2023 at 8:33 AM Philip Kaludercic <philipk@posteo.net> wrote:

> >> [eglot-update] should be deprecated though
> >
> > Noone disagrees with that.  Will do once there is a better alternative,
> > which there isn't atm.
>
> The plan is to address this in Emacs 30, and perhaps even earlier if we
> manage to add package.el to ELPA.

If that plan happens, Emacs 29 users still will need to upgrade a
:core package to get the version of package.el which fixes problems
... with upgrade of :core packages.

João

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  joaotavora@gmail.com
> Date: Fri, 28 Apr 2023 18:12:14 +0000
> 
> 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?

And on top of all that (with which I agree 100%), I explicitly and
repeatedly asked not to introduce this command.