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

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

> > Thing-at-point has been, from the outset, about actual Lisp
> > THINGS, not just strings that name such things.  Yes,
> > string-naming-a-thing is a common use case - the most common,
> > currently.  But it is only part of the story.
> >
> > And yes, buffer text is usually examined to come up with
> > the returned THING.  But the buffer text need not be
> > examined.  What is most significant is point - the buffer
> > position.  And even that could be ignored by the function
> > that comes up with an appropriate THING to return.
> >
> > thingatpt.el is much more general, and offers many more
> > possibilities, than just grabbing some text at or near
> > point.
> 
> Agreed so far, understand that.
> My point is to suggest a restriction here, making the use easier.

What difficulty in use to you see?  What is the difficult-use
problem you are trying to solve?

> If a symbol might return an arbitrary thing doing arbitrary
> actions, why it should reside in this library?

Users of thingatpt.el, including code that uses its features,
will use functions to do THING-related things.  Any "arbitrary"
functions used to come up with an appropriate thing are not, in
practice (i.e., in the real world) not arbitrary.  They are
designed to return a Lisp THING usefully.  And yes, this is all
about obtaining a THING at point.

> Beside this - upholding that in the core, a string is the result in
> any case first.  Follows functions which operate on this string,

It's hard for me to parse what you're saying, but I think your
point is only that buffer text at point is the origin of coming
up with a THING.

That does not at all imply that the THING result is a string.

> derive from its representation a number, intern it or whatever.

What's "its"?  All that serves as input to the function is point
and a buffer (and any global Emacs context - windows etc.).

It is precisely up to the "arbitrary" function to decide just
what part of that (humongous) "its" input it uses as relevant,
and it is up to that function to decide how to use it and what
THING to return.

> For clarification IMO it would be better to separate these
> use-cases from the core-thing.

There is no "core-thing".  The buffer text is only an input.
It is not the THING that is returned.  And even in the case
where a string taken from the buffer text is returned, which
string?  which bit of buffer text?

That's the point.  There are an infinite number of THINGs
that the function could return.  And even picking some buffer
text as the (string) THING to return, there are a myriad (but
in this case not infinite) different string THINGS taken from
buffer text that it could return.  There is NO "core-thing".

It is always up to the function (even in the case of a string
return) to decide what to return and how to obtain it.

> These use-cases are plain operations on strings, nothing
> special to thing-at-point.

There are no "core" or special use cases.  There is nothing
special or more "core" about returning a string value,
whether or not that string is a subsequence of buffer text.