Re: How to read an integer from the minibuffer

[tomas@tuxteam.de]

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

On Sat, Nov 13, 2021 at 09:36:39AM +0300, Jean Louis wrote:
> * tomas@tuxteam.de <tomas@tuxteam.de> [2021-11-12 23:25]:

[...]

> > Why not simply numberp?
> > 
> >   (and (numberp s) (string-to-number s))
> 
> (numberp "123") ⇒ nil
> 
> It checks if object is number. That is why it is not usable to check
> if string is actual number.

D'oh, you are right. That'd been too easy ;-)

It seems you'll have to go with a regexp, then do string-to-number.
Then, again, you'll have to decide: what subset of Emacs's number
input syntax do you want to implement? Signed/unsigned? Integers?
Floats? Exponential notation? Bases other than 10?

As far as Emacs is concerned, for example, this is a number

  #27r21 -> 55

(this would be 21 in base 27). As is this:

  #b10101 -> 21

That gets interesting once you mix multibase ints and floats: is an
e a digit (in a base greater than 14) or the exponential marker?
(my hunch is that floats & exponential notation is only allowed for
base 10, but more doc reading would be necessary).

Or do you want to set the rules, independently of what Emacs lisp
does? Then you better do that explicitly.

I think you only can get down to work once you've cleared that.

To get you started, here would be a regexp to (roughly) accept
floats:

  ^[+-]?[0-9]*\(?:\.[0-9]+\)\(?:[eE][0-9]+\)$

...the backslashes having to be escaped if you put that into a
string, of course.

Add [[:space:]]* in front (or at the end) of it if you want to
accept leading (or trailing) space.

Here's a "packaged" version for the convenience of your buffer:

  (seq-do
   (lambda (tst)
     (insert
      (format
       "'%s' => %s\n"
       tst
       (string-match-p "^[+-]?[0-9]*\\(?:\\.[0-9]+\\)?\\(?:[eE][0-9]+\\)?$" tst))))
   '("123"
     " 123"
     "123 "
     ""
     "."
     "3.141593"
     ".0"
     "1E12"
     "6.02e23"))

Note a couple of things:
 - note that 0 means success: actually `string-match' is
   returning the position where the match starts, and it can
   only be 0, since our regexp is anchored at the beginning
   (^); on failure it returns nil
 - it does accept an empty string. This comes from the fact that
   we allow the part before the decimal point to be empty (we
   might like to accept ".23"), but also the decimal point and
   all that to its right to be missing ("123" is a nice number,
   after all). This can, of course, be fixed. At the cost of an
   uglier regexp or, alternatively, some post-processing-
 - if you are going to accept leading (and trailing? You didn't
   make your position explicit yet) whitespace, you could put
   the "number part" in a capture group \(...\) so you can
   retrieve it after the match.
 - write a series of tests yourself: this will help you to
   better specify what you want to consider as a number
 - other bases are left as an exercise to the reader ;^)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]