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.