bug#24969: 26.0.50; number-at-point

[Tino Calancha]

Drew Adams <drew.adams@oracle.com> writes:

> In Emacs 25.1 (emacs -Q), `number-at-point' at either
> the `-' or the `1' returns nil, for me.  And I do not
> see why it should return a number.
>
> `number-at-point' is defined using `form-at-point' with
> THING `sexp' and predicate `numberp'.  The sexp picked
> up at point is `foo-1', and that fails `numberp'.
>From the time when i opened Bug#24605, the 
implementation, in master branch, of `number-at-point'
was different: it changed in commit 786ab4a5 (Bug#8634).
My patch was driven by this implementation.  I didn't notice
that `number-at-point' behaves different in emacs-25.

> What am I missing?  Why should this rightfully return
> a number?  I'm guessing that you are all using a more
> recent version of `number-at-point' than what is in
> Emacs 25.1 (?).  But to me the Emacs 25.1 behavior I
> see (i.e., returning nil) is correct.
>
> Did someone change the meaning of `number-at-point'
> so that it now picks up a numeral that is not isolated?
> If so, why would that be considered proper behavior?
> At the very least it is not backward-compatible behavior.
That's right.  Commit above breaks backward-compatibility.

>In Lisp, at least, there is no number at point, in `foo-2'.
>That is, the Lisp parser (reader) would never pick up the
>`2' as a number here.
The doc string of `list-at-point' clearly says that the list should
be a Lisp list.  In the case of `number-at-point' the doc string just
says 'the number at point', without connection with the Lisp parser.

>IOW, I agree with the bug report that `form-at-point'
>should - somehow - handle the case where `thing-at-point'
>returns a non-string.  There is a bug to be fixed.  But
>I'm not convinced that the fix we've implemented is TRT.
Sure, I am open to alternative fixes.