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