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.

That is the point of allowing such a function: to let you
control the behavior from outside function `thing-at-point'.
This is similar to passing a function-valued optional parameter
and calling that to provide the behavior.

That's the point of the original design of `thing-at-point':
(1) provide a default, string-producing behavior and (2) also
allow for another function to define the behavior for particular
types of THING.

> If thing-at-point is called with NO-PROPERTIES non-nil, and the
> thing-at-point property returns a string, then any properties
> should be removed from that string, exactly as in the other case.

That overrides the intended behavior of the THING function.
It removes its control, which is there by design.

Sure, you can say that if a caller provides NO-PROPERTIES then
s?he always wants a string value to have properties removed.

I agree that this is not a problem (since the arg is optional,
and new).

However, I really see no reason for NO-PROPERTIES to have ever
been added.  What were we thinking, to do such a thing?  I
cannot imagine a good reason for that change, even if the arg
is optional.  We don't add optional args willy nilly just
because they don't do any harm if they're not called.

And we certainly don't add a NO-PROPERTIES arg to every
function that can return a string.  What is so special about
this function, that it needs such a "feature"?  I haven't
seen an answer to this question yet.

I seriously would propose that we deprecate that optional
arg and return to what was there before it was introduced,
along with this bug.  That was a misguided change, IMO.
It is perhaps no accident that whoever added it introduced
this bug at the same time.  I suspect that the change
betrays a poor understanding of thingatpt.el.

> I don't see why we should single out that one use case.
> I think the only change that makes sense at this point is to replace
> sequencep by stringp, as Tino originally proposed.  Other than that,
> there are no problems here that we need to solve.

I'm OK with that, too.  That was my #3 "reasonable solution":

d> 3. Make `thing-at-point', as before, return just what the firat
      `if' clause returns, if that clause is taken, except that if
      either clause returns a string then strip that string of text
      properties (if NO-PROPERTIES is non-nil).

Fine by me.