bug#24969: 26.0.50; number-at-point

[Drew Adams]

> > 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.
> 
> With 25.1 I get nil, on 26.0.50 I'm getting -1. I believe this is
> due to the fix in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24605

I see.  Dunno what I think about this.  I'd be interested to
hear more from Tino about this.  It clearly is not backward
compatible.  Whether it is an improvement or not, I'm not
sure, in this case.

I guess it depends on what a user would expect of a
"number-at-point" function.  A priori, I don't see why s?he
would expect a non-nil answer if the numeral is embedded in
text that does not delimit a numeral (e.g. non whitespace text).
But maybe it is OK.

Would we expect the same kind of behavior for `sexp-at-point'
if a sexp were not surrounded by chars that delimit a sexp?

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.

I'm partial to use of thingatpt for Lisp, but I realize that
it is used in other contexts too.  I would probably prefer
that, whatever the context, if the context has a notion of
number and its syntax (numerals) then `number-at-point'
would return a number ONLY when there is really a number
at point, based on the meaning of numeral in that context.

If we could do that well, that would be best, I think.  In
the case of Lisp, it is clear (to me) that returning a number
for `foo-2', with point on the `2', is wrong.

I think we need to think more about this.  One option is
to provide two different functions, one of which does what
has been done in the past and one of which tries to be
smarter along the lines of fixing this bug (but not
necessarily along the lines of the implemented fix).

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.

I'm open to being convinced otherwise, but this does not
seeme right to me, so far.  It seems like we should be able
to do better, here.