[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14254: 24.3; read-number fails to recognize faulty numbers (string-t
bug#14254: 24.3; read-number fails to recognize faulty numbers (string-to-number to blame)
Wed, 24 Apr 2013 23:57:18 +0300
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu)
> Try (read-number "Number: ") and insert some non-numeric junk. The
> expected behavior is for the read-number to recognize the faulty string
> and ask again, like documented in (elisp) Interactive Codes:
> A number, read with the minibuffer. If the input is not a number,
> the user has to try again.
`call-interactively' doesn't use `read-number'. It duplicates code
from `read-number' with a similar loop to re-read non-numbers.
However, it uses `read' instead of `string-to-number'.
So I agree it's better to revert the regression and to use `read'
in both `read-number' and `call-interactively' for consistency.
BTW, while comparing `read-number' and `call-interactively'
I noticed a difference between them. Try to evaluate:
(defun read-num (n)
(interactive "nNumber: ")
(message "Number: %s" n))
then `M-x read-num RET non-number RET' clears the prompt to the empty string.
This is because `callint_message' is a global variable whose value gets
cleared while reading a number from the minibuffer recursively.
It should be re-initialized before re-reading the next number.
Since this bug is not a regression, I propose to install this patch to trunk:
=== modified file 'src/callint.c'
--- src/callint.c 2013-02-27 07:42:43 +0000
+++ src/callint.c 2013-04-24 20:54:52 +0000
@@ -692,6 +692,11 @@ (at your option) any later version.
message1 ("Please enter a number.");
sit_for (make_number (1), 0, 0);
+ /* Re-initialize callint_message for next iteration. */
+ if (strchr (SSDATA (visargs), '%'))
+ callint_message = Fformat (i, visargs);
+ callint_message = visargs;
first = 0;