From: Drew Adams <drew.adams@oracle.com>
To: Alan Mackenzie <acm@muc.de>, gnu-emacs-bug@moderators.isc.org
Subject: bug#15433: 24.3.50; wrong-type-argument wholenump -3
Date: Sat, 21 Sep 2013 18:20:23 -0700 (PDT) [thread overview]
Message-ID: <34d7a335-c625-4ae8-b6c3-de3ee74c8777@default> (raw)
In-Reply-To: <<l1l3lt$11hl$1@colin.muc.de>>
> > This regression is from Emacs 24.1 onward. No such problem before that.
>
> You forget to say what the problem is. It isn't obvious.
I didn't forget that. It should be obvious.
The problem is that Emacs gives the user a wrong-type-argument error
in this context. That's a low-level error and message. If the
command raises an error at all in this context then it should show
a user-friendly msg - a message specific to the command.
> > emacs -Q
> > M-x set-variable debug-on-error t
> > M-x M-- 3 f
>
> It appears you are trying to enter -3 f's. This is nonsensical.
Yes. Yes.
> If this isn't what you're trying to do, what is it? Why is that
> error message not the right thing to do?
This is the user providing a prefix arg, which is perfectly normal.
This is not faulty code somewhere providing an arg of the wrong type.
It is a user error to provide a negative prefix arg here.
In Emacs before 24.1, this particular user error was simply ignored.
A better behavior is to raise a reasonable, helpful error for the user.
Pretty much *any* command that does things based on a numeric prefix
arg (or any prefix arg, for that matter), should check whether the
prefix arg value provided by the user makes sense for that command.
The command itself should check. It should not just fall back on
some low-level error handling.
If a numeric prefix arg N is required by some command to be
non-negative, or an odd number, or a power of seven, or whatever,
then any other N that a user provides should result in a reasonable
error message from that command.
Preferably the message would help the user by saying what the command
expects/requires (e.g., N must be a power of seven that is a power of
two).
A user should never, or at least almost never, see a wrong-type-arg msg.
At a minimum, s?he should not see such a msg for cases where it is
easy for Emacs to DTRT and be helpful, i.e., command-specific, with
its message.
next parent reply other threads:[~2013-09-22 1:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<mailman.2673.1379787326.10748.bug-gnu-emacs@gnu.org>
[not found] ` <<l1l3lt$11hl$1@colin.muc.de>
2013-09-22 1:20 ` Drew Adams [this message]
[not found] <mailman.2673.1379787326.10748.bug-gnu-emacs@gnu.org>
2013-09-21 18:13 ` bug#15433: 24.3.50; wrong-type-argument wholenump -3 Drew Adams
2013-09-21 21:39 ` Alan Mackenzie
2014-02-10 4:27 ` Lars Ingebrigtsen
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=34d7a335-c625-4ae8-b6c3-de3ee74c8777@default \
--to=drew.adams@oracle.com \
--cc=acm@muc.de \
--cc=gnu-emacs-bug@moderators.isc.org \
/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).