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

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

> If we agree that the return value of thing-at-point should be a
> string, (get 'number 'thing-at-point) can't return `number-at-point', it
> should return a function that will return the said number as a string.

Oh, God, no.  That would be among the most misguided proposals
I've heard in a long time.  That truly throws out the baby with
the bathwater.

It is not property `thing-at-point' that should return (a function
that returns) a string; it is function `thing-at-point' that should
return a string - if anything should.

> And of all things enumerated in thing-at-point's docstring,

That list is only an indication of some of what is possible.

> IIUC only number has such problem. 

It has no problem that I'm aware of.  What's the problem?
`number-at-point' returns a number, as it should.
`list-at-point' returns a list, as it should, and so on.

(get 'number 'thing-at-point) returns `number-at-point', which
is 100% reasonable.

> Which leaves third-party things, but, they will either need
> to be fixed,

I get the impression that your idea of what is broken and needs
to be fixed is very different from mine.

> or people will have to remain content not to use thing-at-point
> with NO-PROPERTIES argument on them.

What is "them"?

What Eli has suggested is one reasonable approach: just prevent
raising the stupid error.  I proposed at least two other
reasonable approaches.

In none of those suggestions is there a problem with calling
`thing-at-point' on ANY kind of THING while using non-nil
NO-PROPERTIES.

It is not clear what you are seeing as a problem, for which
you think that requiring or prescribing that property
`thing-at-point' return a (function that returns a) string is
the solution.

> I can't imagine that loophole to be too useful. The proposal above
> should leave all such uses of third-party things alone. But yes,
> anyone who uses (thing-at-point 'number) as a (longer, pointless)
> substitute for (number-at-point) will have to change their code.

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.

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. 

> To make thing-at-point behavior more consistent. This kind of thing
> is usually performed with future new uses in mind. But it also might
> help with code maintenance a bit, for existing users (not likely to make
> much of a difference, but still; the danger of breakage is not very
> significant either).

I really disagree with what seems to be your view of thingatpt.el
functionality.

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).