From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org,
joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Fri, 21 Apr 2023 14:05:41 +0300 [thread overview]
Message-ID: <83h6t94hru.fsf@gnu.org> (raw)
In-Reply-To: <8a9d0e2b-6ae2-bcdc-efd0-52a44ac862bb@gutov.dev> (message from Dmitry Gutov on Fri, 21 Apr 2023 13:19:39 +0300)
> Date: Fri, 21 Apr 2023 13:19:39 +0300
> Cc: joaotavora@gmail.com, jporterbugs@gmail.com, 62720@debbugs.gnu.org,
> philipk@posteo.net, monnier@iro.umontreal.ca, larsi@gnus.org
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> On 21/04/2023 09:37, Eli Zaretskii wrote:
>
> >> Why list the commands people use to install packages if we're talking
> >> about upgrading them?
> >
> > I said "to install and upgrade", not just "install".
>
> I listed the upgrade commands.
Yes, and I think we should consider both install and upgrade commands.
> >> Hopefully we'll decide that 'package-install'
> >> won't upgrade packages because it hasn't done that in the past.
> >
> > But it does upgrade non-built-in packages, doesn't it?
>
> Apparently not. I didn't remember whether it does, and I deduced that it
> does just from reading this discussion previously, but it does not.
>
> E.g. just now pressing 'U' after 'M-x list-packages' showed me that I
> have available upgrades for a lot of packages. But still if I evaluate
>
> (package-install 'sml-mode)
>
> where sml-mode is one of said packages, I just get the message:
>
> ‘sml-mode’ is already installed
>
> > And at least
> > João (and I think others as well) expected it to upgrade Eglot even
> > though it is now built in.
>
> I think he wants that because this way (package-install 'eglot) and
> (use-package eglot :ensure t) could match the behavior of Emacs 28 with
> an empty init directory. Backward compatibility and all that.
But if, with older Emacsen, package-install would refuse to update to
a newer version of Eglot if _some_ older version of Eglot is already
installed, then where's the problem with the default behavior of
package-install? it behaves exactly like in previous versions of
Emacs. And why is this a problem for users of Eglot, if they couldn't
use package-install more than once for Eglot anyway?
Something is amiss here.
> But I think that's questionable, semantically. Given that Eglot is
> already "installed". Though, of course, one could argue that a bundled
> package is not exactly installed, but then we should change what
> 'package-installed-p' does as well. And think hard before doing that.
I'd question why we have two commands instead of just one, but that's
probably water under the bridge at this point.
> >>>> - package-upgrade (nee package-update) doesn't upgrade builtin packages
> >>>> that never been upgraded before. It's a bug. Hopefully not too hard to fix.
> >>>
> >>> I'm okay with adding the same prefix argument to package-upgrade,
> >>> which would then allow upgrading a built-in package. IOW, a change
> >>> similar to what we did in package-install -- provided that the change
> >>> is safe enough to go into Emacs 29.
> >>
> >> If we agree it's a bug, why don't we just fix it?
> >
> > Precisely because, as with package-install, this is a bug for some and
> > a feature for others, depending on whether people do or don't want the
> > built-in packages to be upgraded by default.
>
> I'm having a hard time imagining someone evaluating (package-upgrade
> 'eglot) without intention to upgrade it to the latest version. Or
> invoking it interactively with same argument, expecting a different result.
In interactive invocation, package-upgrade calls completing-read with
its 4th argument non-nil, so you cannot select a package which is not
in the collection returned by package--updateable-packages. What I
meant above is to allow that collection to include built-in packages
as optional behavior. I just tried invoking package-update for ElDoc,
and I get "No match" after typing "eldoc" to its prompt, although
eldoc version 1.14.0 is in the list presented by list-packages as
"available".
> >> 'package-update' is an
> >> interactive function which itself it called from only one place:
> >> 'package-update-all', and since the plan is to improve both, we can make
> >> sure they only do what we ask of them: package-update will upgrade
> >> builtins when invoked directly, and package-update-all will upgrade them
> >> only when the builtin has been upgraded before (making it not a builtin
> >> anymore), or a new user option is set.
> >
> > This is one possibility, and it might make sense to some users. But I
> > don't think we can be sure it will make sense to an overwhelming
> > majority of the users.
>
> Hence the user option?
Which one? Are you suggesting to add a new one? If so, why not use
the one we already added, package-install-upgrade-built-in?
> But okay, this particular addition, though trivial, we could probably
> postpone until Emacs 30, or even avoid adding at all. It is indeed not
> obvious that people will really need it, although
If by "this particular addition" you mean to allow package-update to
update built-in packages, then I thought adding that for consistency
with package-install was one of your main bothers? Or what am I
missing?
> (setq package-upgradable-builtins '(eglot use-package))
> (package-upgrade-all)
> ;; or M-x package-upgrade-all
> ;; or 'U' in the list-packages menu
>
> seems like a plausible scenario for a certain kind of user.
Why not treat the fact that some version was already installed from
ELPA as an indication that the user wants this?
> Because
> package-upgrade does not have a menu entry, or a button anywhere,
> whereas package-upgradable-builtins can be altered from the Customize UI.
Maybe marking a package in the list for update could be interpreted as
"upgrade that, no questions asked", and we will need no user options?
> >>> We could make it do that if
> >>> package-install-upgrade-built-in is non-nil -- again, if such a change
> >>> could be safe enough. If not, then the same workaround as for
> >>> package-upgrade would do here, I suppose?
> >>
> >> What workaround would that be? use-package is not invoked interactively
> >> -- there is no prefix argument to pass.
> >
> > The workaround is to manually install the package from ELPA, once,
> > using "C-u M-x package-install RET".
>
> That's not the use-package workflow.
The use-package workflow should perhaps get a separate and different
solution.
> >>>> Whereas I think we originally only wanted that for Eglot and maybe
> >>>> for use-package.
> >>>
> >>> "We" never did want that. João did, for obvious reasons, but that was
> >>> never my intent. The issue is indeed more general: what should
> >>> package-install and package.el in general do with built-in packages
> >>> for which a newer version is on ELPA?
> >>
> >> It could continue doing what it's done before: when a package is already
> >> installed, abort. For upgrading, we should recommend commands with
> >> "upgrade" in their names.
> >
> > If people agree with that, I don't think I'll object. But this is in
> > a sense a breaking change: package-install will only install, and
> > thereafter users will need to use package-upgrade. Some might dislike
> > such behavior changes. And we will need to make sure that all the
> > available methods of "installing" do not "upgrade", for consistency.
>
> Yeah, apparently it won't be a breaking change, or a change at all.
I'm not sure, see above.
Also, when you mark packages for update from the list presented by
list-packages, the menu entry says
i Mark for Install
and its help-echo says "Mark a package for installation and move to
the next line", so we already confuse "install" and "upgrade".
> >>>> For this and other minor reasons I would suggest reverting
> >>>> 580d8278c5f48.
> >>>
> >>> Not going to happen, not unless someone comes up with a better
> >>> solution that is much better and still safe enough. Personally, I
> >>> don't believe such a solution exists, since we don't really know the
> >>> answer to the above question.
> >>
> >> Could you specify which problem it's currently solving? Some particular
> >> scenario.
> >
> > The scenario which started this bug report, see the message whose URL
> > I mentioned above. IOW, we now allow users to explicitly request that
> > package-install includes built-in packages in the list of candidates,
> > and will therefore allow to upgrade them.
>
> After we fix 'package-upgrade', users will be able to 'M-x
> package-upgrade RET eglot RET'.
This goes back to the issue of having two confusingly-similar but
different commands, as mentioned above. I guess we should first make
up our minds what, if anything, we want to do about this.
next prev parent reply other threads:[~2023-04-21 11:05 UTC|newest]
Thread overview: 278+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 22:12 bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot João Távora
2023-04-08 1:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-08 10:43 ` Philip Kaludercic
2023-04-08 10:48 ` João Távora
2023-04-08 14:42 ` Philip Kaludercic
2023-04-08 15:25 ` João Távora
2023-04-08 15:45 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-10 16:01 ` João Távora
2023-04-10 18:13 ` Philip Kaludercic
2023-04-11 11:02 ` João Távora
2023-04-11 11:40 ` Eli Zaretskii
2023-04-11 12:52 ` João Távora
2023-04-11 17:55 ` Eli Zaretskii
2023-04-11 18:31 ` João Távora
2023-04-11 18:52 ` Eli Zaretskii
2023-04-11 20:08 ` João Távora
2023-04-11 20:25 ` João Távora
2023-04-12 5:49 ` Eli Zaretskii
2023-04-12 7:58 ` João Távora
2023-04-12 8:19 ` Eli Zaretskii
2023-04-12 8:51 ` João Távora
2023-04-12 10:23 ` Eli Zaretskii
2023-04-12 10:38 ` João Távora
2023-04-12 11:01 ` Eli Zaretskii
2023-04-12 11:00 ` João Távora
2023-04-12 11:08 ` Eli Zaretskii
2023-04-12 11:15 ` João Távora
2023-04-12 11:22 ` Eli Zaretskii
2023-04-12 11:35 ` João Távora
2023-04-12 11:47 ` Eli Zaretskii
2023-04-12 12:01 ` João Távora
2023-04-12 12:00 ` Philip Kaludercic
2023-04-12 12:18 ` João Távora
2023-04-12 12:28 ` Philip Kaludercic
2023-04-12 12:55 ` João Távora
2023-04-12 12:30 ` Eli Zaretskii
2023-04-12 13:42 ` Philip Kaludercic
2023-04-12 14:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-12 14:14 ` João Távora
2023-04-12 14:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-12 14:20 ` João Távora
2023-04-12 15:18 ` Eli Zaretskii
2023-04-12 16:13 ` João Távora
2023-04-12 16:16 ` João Távora
2023-04-12 16:53 ` Eli Zaretskii
2023-04-12 17:14 ` João Távora
2023-04-12 17:22 ` Eli Zaretskii
2023-04-12 17:43 ` João Távora
2023-04-12 19:09 ` Eli Zaretskii
2023-04-12 19:39 ` Philip Kaludercic
2023-04-13 5:30 ` Eli Zaretskii
2023-04-13 7:38 ` Philip Kaludercic
2023-04-13 8:11 ` Eli Zaretskii
2023-04-13 11:23 ` Philip Kaludercic
2023-04-13 15:03 ` Eli Zaretskii
2023-04-13 15:10 ` Philip Kaludercic
2023-04-13 15:56 ` Eli Zaretskii
2023-04-13 17:49 ` Philip Kaludercic
2023-04-13 18:15 ` Eli Zaretskii
2023-04-13 18:49 ` Philip Kaludercic
2023-04-14 10:54 ` Eli Zaretskii
2023-04-14 12:34 ` Robert Pluim
2023-04-14 12:56 ` João Távora
2023-04-14 13:52 ` Robert Pluim
2023-04-14 15:34 ` João Távora
2023-04-14 15:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-14 16:05 ` João Távora
2023-04-14 16:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-14 16:34 ` Dmitry Gutov
2023-04-14 16:40 ` João Távora
2023-04-14 16:53 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-14 17:49 ` Eli Zaretskii
2023-04-14 18:32 ` João Távora
2023-04-14 18:49 ` Eli Zaretskii
2023-04-14 19:03 ` João Távora
2023-04-14 19:18 ` Eli Zaretskii
2023-04-14 19:31 ` João Távora
2023-04-14 16:12 ` Dmitry Gutov
2023-04-14 16:31 ` João Távora
2023-04-14 16:54 ` Philip Kaludercic
2023-04-14 17:32 ` João Távora
2023-04-14 18:27 ` Philip Kaludercic
2023-04-14 18:39 ` João Távora
2023-04-14 19:33 ` Philip Kaludercic
2023-04-14 19:48 ` João Távora
2023-04-14 17:53 ` Eli Zaretskii
2023-04-14 18:44 ` João Távora
2023-04-14 18:51 ` Eli Zaretskii
2023-04-14 19:14 ` Dmitry Gutov
2023-04-14 19:19 ` Eli Zaretskii
2023-04-14 19:21 ` Dmitry Gutov
2023-04-14 19:30 ` Eli Zaretskii
2023-04-14 19:34 ` João Távora
2023-04-14 19:20 ` João Távora
2023-04-14 19:28 ` Eli Zaretskii
2023-04-14 19:46 ` João Távora
2023-04-14 20:04 ` Philip Kaludercic
2023-04-15 8:35 ` João Távora
2023-04-15 10:40 ` Philip Kaludercic
2023-04-15 10:44 ` João Távora
2023-04-15 12:34 ` Dmitry Gutov
2023-04-15 9:03 ` Eli Zaretskii
2023-04-15 10:24 ` João Távora
2023-04-15 10:28 ` Eli Zaretskii
2023-04-15 11:19 ` Kévin Le Gouguec
2023-04-15 12:33 ` Dmitry Gutov
2023-04-15 13:36 ` João Távora
2023-04-15 16:53 ` Philip Kaludercic
2023-04-15 21:16 ` Kévin Le Gouguec
2023-04-16 10:23 ` João Távora
2023-04-16 20:46 ` Dmitry Gutov
2023-04-16 21:54 ` João Távora
2023-04-17 2:30 ` Eli Zaretskii
2023-04-17 2:24 ` Eli Zaretskii
2023-04-18 1:25 ` Dmitry Gutov
2023-04-18 11:44 ` João Távora
2023-04-18 20:38 ` Dmitry Gutov
2023-04-18 20:56 ` João Távora
2023-04-18 21:06 ` Dmitry Gutov
2023-04-18 21:15 ` João Távora
2023-04-18 21:20 ` Dmitry Gutov
2023-04-19 12:05 ` Eli Zaretskii
2023-04-19 13:04 ` João Távora
2023-04-19 13:35 ` Eli Zaretskii
2023-04-19 14:04 ` João Távora
2023-04-19 16:02 ` Eli Zaretskii
2023-04-19 16:17 ` João Távora
2023-04-19 15:48 ` Dmitry Gutov
2023-04-19 16:10 ` Eli Zaretskii
2023-04-19 16:23 ` João Távora
2023-04-19 16:50 ` Eli Zaretskii
2023-04-19 17:27 ` João Távora
2023-04-19 18:00 ` Eli Zaretskii
2023-04-19 18:27 ` João Távora
2023-04-19 18:48 ` Eli Zaretskii
2023-04-19 17:23 ` Dmitry Gutov
2023-04-19 17:53 ` Eli Zaretskii
[not found] ` <83r0sh8i1q.fsf@gnu.org>
[not found] ` <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com>
[not found] ` <CALDnm53J-HnUz26thrMbFXEARE8yiOJiBb2M75Qm3KKnxRxWzQ@mail.gmail.com>
[not found] ` <87a5z3izst.fsf@web.de>
[not found] ` <83v8hr7qk9.fsf@gnu.org>
[not found] ` <CALDnm51zZw4JhnxCEUApN0N-90c08d-jOct5i2xcTMOhBb78=g@mail.gmail.com>
[not found] ` <83pm7z7nkc.fsf@gnu.org>
[not found] ` <4b63ef62-5e1c-3dcf-ec7b-06b69e79133b@gutov.dev>
[not found] ` <83o7nj7mfn.fsf@gnu.org>
[not found] ` <bd688d7c-1588-43f3-49db-c90d1312fad8@gutov.dev>
[not found] ` <CALDnm5341n=_VtRH2JxsDEH=7uwdsaCQMSCOn+jzDpfnh1qm7A@mail.gmail.com>
[not found] ` <556e0fbb-215e-c11d-0e8b-73e97441abbb@gutov.dev>
[not found] ` <CALDnm52=KRVBn3Zse2DDC-SMHGot0mRpYUEZ7FH5vmAVH4Rimw@mail.gmail.com>
[not found] ` <e3408f6b-f050-a96d-c8c6-5f790cc90df4@gutov.dev>
2023-04-20 10:02 ` Eli Zaretskii
2023-04-20 10:31 ` João Távora
2023-04-20 11:49 ` Eli Zaretskii
2023-04-20 11:53 ` João Távora
2023-04-20 12:14 ` Eli Zaretskii
2023-04-20 13:39 ` Dmitry Gutov
2023-04-20 13:56 ` João Távora
2023-04-20 14:25 ` João Távora
2023-04-20 14:31 ` Dmitry Gutov
2023-04-20 14:40 ` João Távora
2023-04-21 0:22 ` Dmitry Gutov
2023-04-20 14:49 ` Eli Zaretskii
2023-04-20 15:03 ` João Távora
2023-04-20 14:51 ` Philip Kaludercic
2023-04-20 14:30 ` Dmitry Gutov
2023-04-20 14:25 ` Eli Zaretskii
2023-04-20 18:08 ` Robert Pluim
2023-04-20 18:24 ` Philip Kaludercic
2023-04-20 18:53 ` João Távora
2023-04-24 7:48 ` Robert Pluim
2023-04-24 8:57 ` João Távora
2023-04-24 9:38 ` Robert Pluim
2023-04-24 11:43 ` João Távora
2023-04-24 13:01 ` Robert Pluim
2023-04-24 13:08 ` Eli Zaretskii
2023-04-24 13:12 ` Robert Pluim
2023-04-24 20:36 ` Dmitry Gutov
2023-04-24 22:45 ` João Távora
2023-04-21 0:50 ` Dmitry Gutov
2023-04-21 6:37 ` Eli Zaretskii
2023-04-21 10:19 ` Dmitry Gutov
2023-04-21 11:05 ` Eli Zaretskii [this message]
2023-04-21 23:12 ` Dmitry Gutov
2023-04-22 0:57 ` Dmitry Gutov
2023-04-22 8:33 ` Eli Zaretskii
2023-04-22 10:30 ` Dmitry Gutov
2023-04-22 11:11 ` Eli Zaretskii
2023-04-22 11:24 ` Dmitry Gutov
2023-04-22 11:29 ` Dmitry Gutov
2023-04-22 12:01 ` Eli Zaretskii
2023-04-22 12:00 ` Eli Zaretskii
2023-04-22 12:14 ` Dmitry Gutov
2023-04-22 12:24 ` Eli Zaretskii
2023-04-22 23:46 ` Dmitry Gutov
2023-04-23 6:39 ` Eli Zaretskii
2023-04-23 11:58 ` Dmitry Gutov
2023-04-23 13:02 ` Eli Zaretskii
2023-04-23 13:11 ` Dmitry Gutov
2023-04-23 14:24 ` Eli Zaretskii
2023-04-23 21:53 ` Dmitry Gutov
2023-04-24 11:58 ` Eli Zaretskii
2023-04-24 23:45 ` Dmitry Gutov
2023-04-25 7:47 ` Eli Zaretskii
2023-04-25 12:08 ` Dmitry Gutov
2023-04-25 12:12 ` João Távora
2023-04-25 12:43 ` Eli Zaretskii
2023-04-25 18:35 ` Dmitry Gutov
2023-04-26 23:05 ` Dmitry Gutov
2023-04-27 5:41 ` Eli Zaretskii
2023-04-27 9:00 ` Dmitry Gutov
2023-04-27 10:44 ` Eli Zaretskii
2023-04-27 23:51 ` Dmitry Gutov
2023-04-28 5:19 ` Eli Zaretskii
2023-05-04 23:58 ` Dmitry Gutov
2023-05-05 5:04 ` Eli Zaretskii
2023-05-05 5:41 ` Philip Kaludercic
2023-05-05 13:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-05 14:05 ` Eli Zaretskii
2023-05-06 1:02 ` Dmitry Gutov
2023-04-23 13:05 ` Philip Kaludercic
2023-04-23 13:09 ` Dmitry Gutov
2023-04-22 0:57 ` João Távora
2023-04-22 11:38 ` Dmitry Gutov
2023-04-22 12:12 ` João Távora
2023-04-22 8:26 ` Eli Zaretskii
2023-04-22 10:48 ` Dmitry Gutov
2023-04-22 11:20 ` Eli Zaretskii
2023-04-14 13:40 ` Eli Zaretskii
2023-04-14 16:04 ` Dmitry Gutov
2023-04-14 17:43 ` Eli Zaretskii
2023-04-14 17:47 ` Dmitry Gutov
2023-04-14 17:59 ` Eli Zaretskii
2023-04-22 23:37 ` Dmitry Gutov
2023-04-23 13:02 ` Philip Kaludercic
2023-04-23 20:56 ` Dmitry Gutov
2023-04-25 12:24 ` Philip Kaludercic
2023-05-01 2:00 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-13 16:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-13 15:14 ` Philip Kaludercic
2023-04-13 15:59 ` Eli Zaretskii
2023-04-13 16:13 ` Dmitry Gutov
2023-04-13 19:14 ` Philip Kaludercic
2023-04-14 10:56 ` Eli Zaretskii
2023-04-14 16:40 ` Philip Kaludercic
2023-04-15 8:37 ` Eli Zaretskii
2023-04-15 10:41 ` Philip Kaludercic
2023-04-15 10:56 ` Eli Zaretskii
2023-04-15 11:37 ` Philip Kaludercic
2023-04-15 11:43 ` Eli Zaretskii
2023-04-15 13:21 ` Philip Kaludercic
2023-04-15 13:51 ` Eli Zaretskii
2023-04-15 17:14 ` Philip Kaludercic
2023-04-15 17:37 ` Eli Zaretskii
2023-04-15 18:19 ` Philip Kaludercic
2023-04-15 18:37 ` Eli Zaretskii
2023-04-16 13:45 ` Philip Kaludercic
2023-04-16 15:12 ` Eli Zaretskii
2023-04-16 10:44 ` João Távora
2023-04-16 14:23 ` Kévin Le Gouguec
2023-04-12 20:10 ` Philip Kaludercic
2023-04-13 5:49 ` Eli Zaretskii
2023-04-12 15:49 ` Dmitry Gutov
2023-04-12 15:59 ` Eli Zaretskii
2023-04-12 16:29 ` João Távora
2023-04-12 20:50 ` Dmitry Gutov
2023-04-12 15:45 ` Dmitry Gutov
2023-04-11 18:54 ` Eli Zaretskii
2023-04-11 20:28 ` João Távora
2023-04-12 5:51 ` Eli Zaretskii
2023-04-12 9:18 ` João Távora
2023-04-12 9:53 ` Eli Zaretskii
2023-04-12 12:37 ` João Távora
2023-04-12 13:20 ` Philip Kaludercic
2023-04-12 16:54 ` Eli Zaretskii
2023-04-11 19:44 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-11 20:05 ` João Távora
2023-04-11 21:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-12 7:34 ` Philip Kaludercic
2023-04-12 5:44 ` Eli Zaretskii
2023-04-12 7:44 ` Philip Kaludercic
2023-04-12 8:10 ` Eli Zaretskii
2023-04-12 14:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-11 21:14 ` Dmitry Gutov
2023-04-12 9:34 ` João Távora
2023-04-12 15:38 ` Dmitry Gutov
2023-04-08 7:10 ` Eli Zaretskii
2023-04-08 9:09 ` João Távora
2023-04-08 14:51 ` Ihor Radchenko
2023-04-08 15:23 ` João Távora
2023-04-08 15:31 ` Ihor Radchenko
2023-04-08 18:10 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83h6t94hru.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=62720@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=joaotavora@gmail.com \
--cc=jporterbugs@gmail.com \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=philipk@posteo.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).