From: Philip Kaludercic <philipk@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Dmitry Gutov <dmitry@gutov.dev>,
monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
Date: Sun, 07 May 2023 08:46:53 +0000 [thread overview]
Message-ID: <87h6sofs02.fsf@posteo.net> (raw)
In-Reply-To: <83v8h4elki.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 May 2023 08:51:09 +0300")
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
next prev parent reply other threads:[~2023-05-07 8:46 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <168335548287.8529.4912240840977468283@vcs2.savannah.gnu.org>
[not found] ` <20230506064443.56C75C22F15@vcs2.savannah.gnu.org>
2023-05-06 10:14 ` emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change Dmitry Gutov
2023-05-06 10:35 ` Eli Zaretskii
2023-05-06 10:46 ` Dmitry Gutov
2023-05-06 10:53 ` Eli Zaretskii
2023-05-06 13:03 ` João Távora
2023-05-06 13:22 ` Eli Zaretskii
2023-05-06 13:48 ` João Távora
2023-05-06 14:11 ` Eli Zaretskii
2023-05-06 14:45 ` Eli Zaretskii
2023-05-06 15:28 ` Dmitry Gutov
2023-05-06 15:26 ` Dmitry Gutov
2023-05-06 15:44 ` Eli Zaretskii
2023-05-06 15:54 ` Dmitry Gutov
2023-05-06 16:40 ` Eli Zaretskii
2023-05-06 18:44 ` Philip Kaludercic
2023-05-06 19:08 ` Eli Zaretskii
2023-05-07 7:43 ` Philip Kaludercic
2023-05-06 19:15 ` Dmitry Gutov
2023-05-06 19:14 ` Dmitry Gutov
2023-05-06 19:38 ` Eli Zaretskii
2023-05-06 20:31 ` Dmitry Gutov
2023-05-06 20:52 ` João Távora
2023-05-07 5:51 ` Eli Zaretskii
2023-05-07 8:46 ` Philip Kaludercic [this message]
2023-05-07 9:32 ` Eli Zaretskii
2023-05-07 17:16 ` Philip Kaludercic
2023-05-07 18:32 ` Eli Zaretskii
2023-05-07 19:24 ` Philip Kaludercic
2023-05-07 19:32 ` Eli Zaretskii
2023-05-07 19:44 ` Philip Kaludercic
2023-05-08 11:19 ` Eli Zaretskii
2023-05-12 12:35 ` Eli Zaretskii
2023-05-08 11:20 ` Eli Zaretskii
2023-05-08 13:34 ` Philip Kaludercic
2023-05-08 13:44 ` Eli Zaretskii
2023-05-10 6:59 ` Philip Kaludercic
2023-05-10 11:03 ` Philip Kaludercic
2023-05-10 14:06 ` Eli Zaretskii
2023-05-10 15:02 ` Ruijie Yu via Emacs development discussions.
2023-05-11 7:29 ` Philip Kaludercic
2023-05-10 22:19 ` Dmitry Gutov
2023-05-11 7:26 ` Philip Kaludercic
2023-05-11 9:43 ` Dmitry Gutov
2023-05-11 10:46 ` Eli Zaretskii
2023-05-12 6:43 ` Philip Kaludercic
2023-05-07 20:36 ` Dmitry Gutov
2023-05-08 11:24 ` Eli Zaretskii
2023-05-08 21:39 ` Dmitry Gutov
2023-05-12 12:34 ` Eli Zaretskii
2023-05-07 9:50 ` Dmitry Gutov
2023-05-07 10:55 ` Eli Zaretskii
2023-05-06 16:58 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6sofs02.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.