From: Al Petrofsky <al@petrofsky.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 64138@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#64138: 28.2; C-x ) won't accept the universal argument
Date: Sun, 18 Jun 2023 07:00:44 -0400 [thread overview]
Message-ID: <CAPMQwz64_sqgb83tKL1jEX5Rc6wB-r2qYf=HePFDAr5q6=YAiQ@mail.gmail.com> (raw)
In-Reply-To: <83fs6pp8l1.fsf@gnu.org>
[-- 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 --]
next prev parent reply other threads:[~2023-06-18 11:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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='CAPMQwz64_sqgb83tKL1jEX5Rc6wB-r2qYf=HePFDAr5q6=YAiQ@mail.gmail.com' \
--to=al@petrofsky.org \
--cc=64138@debbugs.gnu.org \
--cc=eliz@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 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).