bug#14254: 24.3; read-number fails to recognize faulty numbers (string-to-number to blame)

[Juri Linkov]

> 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:
>
>    `n'
>         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[0]), '%'))
+                     callint_message = Fformat (i, visargs);
+                   else
+                     callint_message = visargs[0];
                  }
                first = 0;