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: Philip Kaludercic
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Thu, 13 Apr 2023 18:49:05 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> 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 17:49:00 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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?
>> 
>> I was thinking about both, but I supposed that a user option would be
>> enough.
>
> No, I think having both is better.  It is easier to say "C-u" than to
> change the value of an option, so for one-off update of a single
> package, the prefix argument is more convenient.
>
>> >> 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?
>> 
>> No, it just prints that message but doesn't download anything.
>
> OK, then allowing to install such packages under the proposed changes
> will improve that case as well.

After having added the user option, I am not sure about the prefix
argument.  I see this as a temporary fix due to the time constraints of
releasing Emacs 29.  It is disabled for now, but can be enabled on
master to see if there are any problems.

But for now, this patch supports both the user option and the prefix
argument.  I am still not satisfied with the documentation, but cannot
come up with a better phrase than

  installing potentially newer versions of built-in packages from
  package archives

for explaining the issue without getting too technical.  Do you have any
ideas?

Attachment: 0001-Allow-upgrading-built-in-packages-with-package-insta.patch
Description: Text Data


reply via email to

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