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.