emacs-devel
[Top][All Lists]
Advanced

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

Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last ch


From: Philip Kaludercic
Subject: Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
Date: Sun, 07 May 2023 08:46:53 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 6 May 2023 23:31:31 +0300
>> Cc: philipk@posteo.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> On 06/05/2023 22:38, Eli Zaretskii wrote:
>> >> package-menu-mark-upgrades ('U') is not affected by
>> >> package-install-upgrade-built-in. It won't.
>> > 
>> > Shouldn't it?
>> 
>> Maybe, maybe not.
>
> I think it better did, because using "U" would upgrade Eglot and
> use-package in Emacs 28 and before.  So we should give users who want
> that the capability of keeping that workflow in Emacs 29, if only as
> opt-in behavior.

"Workflow" is really to high of a term for the problem being discussed
here.  Installing packages is not a periodical thing people to on a
regular basis.

> Also, "/ u" should ideally show built-in packages as well, when
> package-install-upgrade-built-in is non-nil.

So the point here would be that a user who enables this option, regards
any newer version of a core-package on ELPA as something that should be
installed?

Perhaps this is a tangent, but what would happen if a third-party
repository like MELPA adds a package with the same name as a core
package?

> Philip, can these two changes be implemented safely for Emacs 29?

It certainly can be done.

>> A user that customized that option to have (package-install 'eglot) 
>> ensure that a version from ELPA is installed might not want or expect 
>> for it to affect package-menu-mark-upgrades and/or package-upgrade-all. 
>
> That is true, but denying them the possibility of upgrading would be
> worse, I think.  And since this is opt-in behavior, the user is less
> likely to be tripped by that without realizing it.
>
>> Or anticipate the full consequences anyway.
>
> Documentation should solve this aspect.
>
>> >>> If package-upgrade was not in Emacs 28, how did users upgrade
>> >>> installed packages in Emacs 28 and before?
>> >>
>> >> Using package-menu-mark-upgrades ('U').
>> > 
>> > So we should allow that, at least as an optional behavior in Emacs 29,
>> > right?
>> 
>> I don't believe in "optionality" here.
>> 
>> If the user has to hunt for the option to toggle, they might as well 
>> find the "one little trick" that does the thing they want.
>> 
>> Most people will only have to do that once (per config), if at all: 
>> after Eglot is upgraded this way, it's smooth sailing from then on.
>
> I think allowing such an optional behavior and documenting it in NEWS
> and in the manual should go a long way towards eliminating at least
> some of your fears.
>
>> >> We should probably focus on getting Emacs 29 out soon
>> > 
>> > Why do you think this is not what happens?
>> 
>> I'm just saying we've spent enough time on this particular issue. We can 
>> improve the docs the best we can and move on.
>
> This is not the only issue that holds the next pretest.  So nothing is
> lost by spending some more time on this, especially since it's now
> clear the original longish discussion was at least partially based on
> some kind of Rashomon effect.

-- 
Philip Kaludercic



reply via email to

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