* bug#64138: 28.2; C-x ) won't accept the universal argument
@ 2023-06-17 23:47 Al Petrofsky
2023-06-18 6:50 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Al Petrofsky @ 2023-06-17 23:47 UTC (permalink / raw)
To: 64138
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]
emacs-28.2 -Q -nw
C-x ( x C-u C-x )
The C-u C-x ) should complete the macro definition and then execute
the macro three times, making the buffer contents "xxxx". Instead,
the error "Wrong type argument: fixnump, (4)" occurs.
(Changing "C-u" to "C-u 4" gives the expected result.)
The "P" in the interactive declaration of kmacro-end-macro should be a
"p".
Looking at all eleven "P" in kmacro.el, I think four of them should be
"p": kmacro-call-ring-2nd, kmacro-call-ring-2nd-repeat,
kmacro-end-macro, and kmacro-end-and-call-macro.
Alternatively, if the meaning of a bare C-u argument is being reserved
for some future feature, then it should be explicitly mentioned in the
documentation that C-u and C-u 4 are treated differently. As the
manual says:
A few commands treat a plain ‘C-u’ differently from an ordinary
argument. A few others may treat an argument of just a minus sign
differently from an argument of −1. These unusual cases are described
when they come up; they exist to make an individual command more
convenient, and they are documented in that command’s documentation
string.
[-- Attachment #2: Type: text/html, Size: 1369 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#64138: 28.2; C-x ) won't accept the universal argument
2023-06-17 23:47 bug#64138: 28.2; C-x ) won't accept the universal argument Al Petrofsky
@ 2023-06-18 6:50 ` Eli Zaretskii
2023-06-18 11:00 ` Al Petrofsky
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Eli Zaretskii @ 2023-06-18 6:50 UTC (permalink / raw)
To: Al Petrofsky, Stefan Monnier; +Cc: 64138
> From: Al Petrofsky <al@petrofsky.org>
> Date: Sat, 17 Jun 2023 19:47:47 -0400
>
> emacs-28.2 -Q -nw
> C-x ( x C-u C-x )
>
> The C-u C-x ) should complete the macro definition and then execute
> the macro three times, making the buffer contents "xxxx". Instead,
> the error "Wrong type argument: fixnump, (4)" occurs.
>
> (Changing "C-u" to "C-u 4" gives the expected result.)
>
> The "P" in the interactive declaration of kmacro-end-macro should be a
> "p".
These commands always required a numeric prefix argument, and that is
how they are documented. So just "C-u" is invalid, you should use
"C-u 4" instead.
I have no objections to extending those commands to accept just C-u,
though. Stefan, any reasons why not?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#64138: 28.2; C-x ) won't accept the universal argument
2023-06-18 6:50 ` Eli Zaretskii
@ 2023-06-18 11:00 ` Al Petrofsky
2023-06-18 11:05 ` Eli Zaretskii
2023-06-18 13:05 ` Drew Adams
2023-06-18 13:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 1 reply; 8+ messages in thread
From: Al Petrofsky @ 2023-06-18 11:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 64138, Stefan Monnier
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
> > The C-u C-x ) should complete the macro definition and then execute
> > the macro three times
> These commands always required a numeric prefix argument
The kmacro-end-macro command has always used the wrong interactive
spec, but C-u C-x ) worked in Emacs 1.9 through 21.4, when C-x ) was
bound to end-kbd-macro, which has always used "p".
> These commands always required a numeric prefix argument, and that
> is how they are documented. So just "C-u" is invalid, you should
> use "C-u 4" instead.
Hmm, kmacro-end-macro's doc string copied this paragraph verbatim from
end-kbd-macro:
With numeric arg, repeat macro now that many times,
counting the definition just completed as the first repetition.
An argument of zero means repeat until error.
So you're saying that end-kbd-macro was always documented wrong, and
should have pointed out that C-u works? I take the manual to be
saying that C-u meaning C-u 4 is the norm, and it is the functions
that are exceptions to that norm that need to clearly document that
exception:
A few commands treat a plain ‘C-u’ differently from an ordinary
argument. A few others may treat an argument of just a minus sign
differently from an argument of −1. These unusual cases are described
when they come up; they exist to make an individual command more
convenient, and they are documented in that command’s documentation
string.
[-- Attachment #2: Type: text/html, Size: 1623 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#64138: 28.2; C-x ) won't accept the universal argument
2023-06-18 11:00 ` Al Petrofsky
@ 2023-06-18 11:05 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2023-06-18 11:05 UTC (permalink / raw)
To: Al Petrofsky; +Cc: 64138, monnier
> From: Al Petrofsky <al@petrofsky.org>
> Date: Sun, 18 Jun 2023 07:00:44 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 64138@debbugs.gnu.org
>
> > These commands always required a numeric prefix argument, and that
> > is how they are documented. So just "C-u" is invalid, you should
> > use "C-u 4" instead.
>
> Hmm, kmacro-end-macro's doc string copied this paragraph verbatim from
> end-kbd-macro:
>
> With numeric arg, repeat macro now that many times,
> counting the definition just completed as the first repetition.
> An argument of zero means repeat until error.
>
> So you're saying that end-kbd-macro was always documented wrong, and
> should have pointed out that C-u works?
No, I'm saying that just "C-u" is not a "numeric argument".
> I take the manual to be
> saying that C-u meaning C-u 4 is the norm, and it is the functions
> that are exceptions to that norm that need to clearly document that
> exception:
>
> A few commands treat a plain ‘C-u’ differently from an ordinary
> argument. A few others may treat an argument of just a minus sign
> differently from an argument of −1. These unusual cases are described
> when they come up; they exist to make an individual command more
> convenient, and they are documented in that command’s documentation
> string.
Yes, which is why it would be good to make these commands behave
closer to the general principle that the manual describes. I'm just
saying that they never did until now. Which is completely legitimate,
since what these commands do is not easily and obviously categorized
as repeatable operations: the argument makes them repeat some part of
what the command does.
Anyway, I think we agree that it would be a good extension, so no need
to argue any longer. I'd just want to hear from Stefan whether we are
missing some subtlety here.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#64138: 28.2; C-x ) won't accept the universal argument
2023-06-18 6:50 ` Eli Zaretskii
2023-06-18 11:00 ` Al Petrofsky
@ 2023-06-18 13:05 ` Drew Adams
2023-06-18 13:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 0 replies; 8+ messages in thread
From: Drew Adams @ 2023-06-18 13:05 UTC (permalink / raw)
To: Eli Zaretskii, Al Petrofsky, Stefan Monnier; +Cc: 64138@debbugs.gnu.org
> > (Changing "C-u" to "C-u 4" gives the expected result.)
> > The "P" in the interactive declaration of kmacro-end-macro
> > should be a "p".
>
> These commands always required a numeric prefix argument, and that is
> how they are documented. So just "C-u" is invalid, you should use
> "C-u 4" instead.
I thought it was the case that unless specified
otherwise (i.e., unless C-u has another behavior),
when a numeric prefix arg has some behavior then
a plain C-u should act the same as C-u 4 (etc.).
I thought that when doc says _only_ "with numeric
prefix arg..." or "a numeric prefix arg means..."
that's short for an equivalent statement about
plain C-u (and its multiples), plain M--, etc.
I thought that any departure from this general
rule would be mentioned in the doc, including if
plain C-u were ignored or raised an error or...
Hasn't this been the (unwritten) convention?
(Just asking a question - not arguing.)
In this case, if plain C-u were indeed "invalid"
then I'd expect that to be documented.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#64138: 28.2; C-x ) won't accept the universal argument
2023-06-18 6:50 ` Eli Zaretskii
2023-06-18 11:00 ` Al Petrofsky
2023-06-18 13:05 ` Drew Adams
@ 2023-06-18 13:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-18 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-18 13:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Al Petrofsky, 64138
> I have no objections to extending those commands to accept just C-u,
> though. Stefan, any reasons why not?
Offhand, I can't think of any reason why not.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#64138: 28.2; C-x ) won't accept the universal argument
2023-06-18 13:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-18 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-21 14:02 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-18 14:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Al Petrofsky, 64138
>> I have no objections to extending those commands to accept just C-u,
>> though. Stefan, any reasons why not?
> Offhand, I can't think of any reason why not.
BTW: the main question here is whether a C-1 prefix should be treated
the same as the absence of a prefix. AFAICT, the `arg` argument
of `kmacro-end-macro` is only used once, to pass it to `end-kbd-macro`,
and that function starts with:
if (NILP (repeat))
XSETFASTINT (repeat, 1);
else
CHECK_FIXNUM (repeat);
so, the absence of a prefix arg currently should indeed always behave
exactly as with a `C-1` arg.
IOW, I'm pretty sure now that there is not reason why not.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#64138: 28.2; C-x ) won't accept the universal argument
2023-06-18 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-21 14:02 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2023-06-21 14:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: al, 64138-done
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Al Petrofsky <al@petrofsky.org>, 64138@debbugs.gnu.org
> Date: Sun, 18 Jun 2023 10:08:04 -0400
>
> >> I have no objections to extending those commands to accept just C-u,
> >> though. Stefan, any reasons why not?
> > Offhand, I can't think of any reason why not.
>
> BTW: the main question here is whether a C-1 prefix should be treated
> the same as the absence of a prefix. AFAICT, the `arg` argument
> of `kmacro-end-macro` is only used once, to pass it to `end-kbd-macro`,
> and that function starts with:
>
> if (NILP (repeat))
> XSETFASTINT (repeat, 1);
> else
> CHECK_FIXNUM (repeat);
>
> so, the absence of a prefix arg currently should indeed always behave
> exactly as with a `C-1` arg.
> IOW, I'm pretty sure now that there is not reason why not.
OK, thanks. I've now installed this on the master branch, and I'm
closing this bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-06-21 14:02 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-17 23:47 bug#64138: 28.2; C-x ) won't accept the universal argument Al Petrofsky
2023-06-18 6:50 ` Eli Zaretskii
2023-06-18 11:00 ` Al Petrofsky
2023-06-18 11:05 ` Eli Zaretskii
2023-06-18 13:05 ` Drew Adams
2023-06-18 13:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-18 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-21 14:02 ` Eli Zaretskii
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).