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

[Drew Adams]

> > > > d> 2. Make `thing-at-point', as before, return just what the
> > > >       firat `if' clause returns, if that clause is taken.
> > > >       IOW, move the removal of text properties (from non-nil
> > > >       NO-PROPERTIES) into the second `if' clause.
> > >
> > > Why would we want to do that?  AFAIU, it would require the
> > > function that is the value of the thing-at-point property to
> > > second-guess what the caller of thing-at-point wants, something
> > > it has no means to do.
> >
> > Quite the contrary.  It gives the function that is the value of
> > the property the ability to determine the return value.  Which
> > is precisely the intended behavior of that property, from the
> > start.
> 
> So you are saying that the function should control the caller,
> instead of the other way around?  That makes very little sense to me,
> because the function writer has no way of knowing the caller's intent.

If the THING has property `thing-at-point' then the function that
is the value of that property controls the behavior of function
`thing-at-point' _for that type of THING_.  Yes.

That is the design.  And of course you can override the behavior
locally or temporarily by removing the symbol property (and then
restoring it).  You can, similarly, change the symbol property,
to locally or temporarily get different behavior.  I don't see
that being done often.  I've never seen it done, in practice -
but it could be done.

All this just means that what you call the "caller", function
`thing-at-point', does not have its behavior decided/defined
once and for all, ahead of time.  Its behavior is controlled
by the symbol property, in addition to the `thing-at-point'
defun.

Again, this is very similar (it is equivalent) to what happens
when you pass a function-valued parameter to a higher-order
function.  In effect, `thing-at-point' is a higher-order function,
because of symbol-property `thing-at-point'.

Being able to put the property on specific THING symbols is a
way of making the higher-order nature more specific (THING
type-specific).

And (except for the fact that the property value could be
changed at runtime) this differs from passing a function-valued
parameter that is computed at runtime: with this design, the
THING-specific behavior is defined at coding time, not at
runtime.

A user or a 3rd-party library can easily define a specialized
(including a personally preferred) behavior for a given THING
type, simply by setting property `thing-at-point'.  No advising
needed.  (You can think of it as a kind of hook, if you like.)