bug#24969: 26.0.50; number-at-point

[Drew Adams]

> > But the question is, "What constitutes a numeral?" in the given
> > context.  Whatever the context, I would expect some kind of
> > well-defined delimiting.  In Lisp I would expect what the Lisp
> > reader would pick up as a number - nothing more.
> 
> The perspective of the lisp-programmer and the user of an editor may
> be different here.

Too vague.

> The implementation at progress should pick any valid hex- octal- or
> decimal integer at point.

I disagree.  Users should control whether they want a decimal,
octal, or hex number at point - or any kind of number.  Those
are different things.  In my code I define hex and decimal number
at point functions.  When code wants to get only a decimal number
it does not want to pick up `FACE'.  When code wants an octal
number it does not want `987'.

And nothing prevents a given context from defining a "number"
category.  That's we had, for Lisp numbers.  Other modes are
free to define a number syntax such that the (previous)
implementation of `number-at-point' - or any local,
mode/context-specific implementation, is in charge.

> In a related case even characters are raised here, returning
> a "b" for an "a", an "y" for an "x" etc.

Far too loose and useless.  Thingatpt lets you define any number
of specific kinds of things.  A predefined catch-all that does
lots of things that are not clear is not helpful.

> > In Lisp I would expect what the Lisp reader would pick up
> > as a number - nothing more.  And that would exclude picking
> > up `2' within `foo-2'.
> 
> Not, when for example filenames inside shell-scripts etc. are
> edited.

What part of Lisp reader was not clear?  The (previous)
implementation uses what the current mode considers a number.
It is based on the Lisp reader, but users (or Emacs) can define
other number readings.