bug#21391: 24.5; `thing-at-point' should return a string

[Drew Adams <drew.adams@oracle.com>]

> And another inconsistency:
> (bounds-of-thing-at-point 'number) always returns nil.

It's not an inconsistency.  It's a bug.

`thingatpt.el' HAS bugs.  I've provided patches and filed bug
reports, pointing to code that fixes things.  All of that has
been ignored.  I've been using the fixed code for years, and
so have others.

In my code I do this, and things work fine:

(put 'number 'tap-bounds-of-thing-at-point 'tap-bounds-of-number-at-point)

(defun tap-bounds-of-number-at-point ()
  "Return the bounds of the number represented by the numeral at point.
Return nil if none is found."
  (and (number-at-point)  (tap-bounds-of-thing-at-point 'sexp)))

`bounds-of-thing-at-point' is broken.  I've provided a fix for it, which
you've rejected summarily, based on your own perceived "need" to force
`thing-at-point' to not respect "at point" but try to return things that
are only near point - things that are either here or there - no "at".

> We won't lose that if we go with either of my proposals: instead of
> printing objects inside the thing-at-point function, we would
> require that each returned thing is a string already. Any thing-at-point
> function that returns a non-string will be considered non-conformant.

You want to throw out the baby with the bathwater.  You have no use
for what is truly useful in thingatpt.  You ignore the design and
insist on your own interpretation of what's "useless" or "inconsistent".