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

[Drew Adams]

> > (get 'number 'thing-at-point) returns `number-at-point', which
> > is 100% reasonable.
> 
> Not at all. As I've explained previously.

No, you have not.  This is the whole point of symbol property
`thing-at-point', and it always has been.

What do YOU think is the point of putting property `thing-at-point'
on a THING type?

> > Not wanting someone to use (thing-at-point 'number) to return
> > a number via (get 'number 'thing-at-point) is one thing.
> > And it is already addressed by what I proposed.
> 
> I must have missed that proposal.

I showed three possibilities, and I pointed out which one I prefer.
The bug thread is there, in case you really missed it.

> > Not wanting to let (get 'number 'thing-at-point) to return a
> > function that returns a number is quite another thing altogether.
> > And it is totally uncalled for.
> 
> Isn't that one and the same?

Of course not.  The use of (get 'number 'thing-at-point) in the
definition of `thing-at-point' is only _one_ use of it.  That's
apparently what you've missed from the beginning: the point of
symbol property `thing-at-point'.

You will see things like this in thingatpt.el:

(put 'url 'thing-at-point 'thing-at-point-url-at-point)

(put 'email 'thing-at-point
     (lambda ()
       (let ((boundary-pair (bounds-of-thing-at-point 'email)))
         (if boundary-pair
             (buffer-substring-no-properties
              (car boundary-pair) (cdr boundary-pair))))))

(put 'number 'thing-at-point 'number-at-point)

And that's only a few predefined uses of it.  One of the main
points of the library is to provide tools that you can use to
define your functions that implement providing a THING at point.
And by that I do not mean just a string at point that names a
thing - I mean a Lisp THING (list, sexp, number, color name,
file name,... whatever).

It is irrelevant to the design of thingatpt.el, and its intended
use cases, that the THINGs defined for `url' and `email' are
string values.  They are no more "normal" cases for the design
than is `number'.  What is important is that the design provides
this functionality for _any_ kind of THING - any Lisp value.

Examples of other THING-returning definitions:

(put 'list 'thing-at-point 'my-list-at-point)
(put 'unquoted-list 'thing-at-point 'my-unquoted-list-at-point)
(put 'non-nil-symbol-name 'thing-at-point 'my-non-nil-symbol-name-at-point)
(put 'symbol-name 'thing-at-point 'my-symbol-name-at-point)
(put 'region-or-word 'thing-at-point 'my-region-or-word-at-point)
(put 'color 'thing-at-point 'my-color-at-point)
(put 'decimal-number 'thing-at-point 'my-number-at-point-decimal)
(put 'hex-number 'thing-at-point 'my-number-at-point-hex)
(put 'string 'thing-at-point 'my-string-at-point)

Some of those THING types are strings; some are lists; some are
symbols; some are numbers.  The THING possibilities are limitless.

Practically the entire design of thingatpt.el revolves around
putting properties on THING-type symbols and function symbols.
This includes property `thing-at-point'.

> > I disagreed with it strongly in the context of bug #9300, where
> > you were the lone voice proclaiming it.  You apparently view the only
> > use of this functionality as returning a string near (not at)
> > point that can be used as an input default value.  thingatpt.el is much
> > more than that.  It is very important that it be able to be used
> > to test whether there (really) is a given THING _at_ point (not
> > just somewhere near point).
> 
> That seems orthogonal to the current discussion.

It points to the fact that you apparently have only a limited view
of what thingatpt.el is for and what features it provides.  You've
missed two for two, so far - and important ones, at that.