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

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

> > All this just means that what you call the "caller", function
> > `thing-at-point',
> 
> No, the caller is whoever calls thing-at-point the function.  Only
> that caller knows whether the text properties on any text the
> function returns are wanted or not, which is why the caller can use the
> NO-PROPERTIES argument to express the intent.

I misspoke there.  That is what I meant - the calling sequence,
not the defun of `thing-at-point'.

The point of the other approach is that if another function
(on the THING-symbol property) determines the `thing-at-point'
function behavior then that applies to a string value that it
might return, as well.  That enables a THING-specific behavior
that can return a propertized string - yes, overriding callers
that provide non-nil NO-PROPERTIES.

IOW, with the other approach "the behavior is controlled by the
symbol property, in addition to the `thing-at-point' defun."
And that includes the part of the defun that tries to respect
argument NO-PROPERTIES.

It's a design choice.

There is no golden rule about this.  Emacs lets things that are
outside a defun AND things that are outside a calling sequence
change the behavior of a called function.  There are umpteen ways
that this is allowed, from binding variables around code that
eventually calls "the caller" (reaching deep inside) to advising,
to hooks, to, yes, fiddling with symbol properties.

As I said, I'm fine with either approach.  One gives some more
control to the symbol property (which, remember, can be used
by "calling" code and users).  The other gives more control to
a given call.

And note, again, that if we got rid of the ill-designed
NO-PROPERTIES arg then the behavior you prefer would be used:
Calling code would remove properties separately, after the
string is returned.