unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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 --]

  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).