bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot


From: Eli Zaretskii
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Thu, 13 Apr 2023 18:56:08 +0300

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: joaotavora@gmail.com,  monnier@iro.umontreal.ca,  62720@debbugs.gnu.org,
>   larsi@gnus.org
> Date: Thu, 13 Apr 2023 15:10:01 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The issue here is that this breaks the non-interactive invocations like
> >> (package-install 'eglot), unless they invoke the function while binding
> >> `current-prefix-arg', which I don't think is a common practice.
> >
> > Then let's add another optional argument, and let prefix arg set it.
> > Would that resolve this issue?
> 
> That could solve it, but a user option might be more elegant.  We could
> set it to nil for now, and change it to non-nil for the next release.

Adding an option is fine by me, as long as its default preserves
previous behavior.

Just to be sure we are on the same page: you suggest _both_ prefix
argument and user option, where user option could be used to avoid the
need for prefix argument?

> >> >> Note that (package-install 'eglot) does download code, but I believe
> >> >> that this is the correct approach and would align with what João
> >> >> wanted.
> >> >
> >> > I'm not sure I follow: which code does the above download?
> >> 
> >> I did not change any of the code that downloads anything, all this does
> >> is prompt the user for built-in packages when invoked interactively with
> >> a prefix argument and if package-install is invoked with a built-in
> >> package, then it will switch to the ELPA version.  This will not happen
> >> in interactive usage, since `completing-read' is called with
> >> REQUIRE-MATCH.
> >
> > So you are saying that non-interactive calls to package-install could
> > install Eglot from ELPA even without the changes, is that right?
> 
> No, my proposed diff changes what package decides to download (the
> planning phase), but doesn't touch anything after that.  The current
> state is that (package-install 'eglot) just prints
> 
>   ‘eglot’ is already installed

And does nothing else?  You seem to be saying it still downloads
something, but what is that?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]