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

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

> I'm not sure what issue we are discussing and what problem we are
> trying to solve.  Let me take a step back and describe the situation
> as I see it.
> 
> This bug report started because thing-at-point would signal an error
> for some of its calls.  That bug is already fixed.  Tino was unhappy
> with using sequencep and wanted to replace that with stringp -- fine
> with me, I don't object to such a change.
> 
> From my POV the issue should be closed once we agree on the
> predicate
> to use when deciding whether or not stripping the text properties is
> appropriate.
> 
> But then somehow the discussion shifted to be about whether to
> _force_ thing-at-point value to be a string, even if it isn't
> for some reason.
>
> I don't understand the rationale for such a change.  Yes,
> thing-at-point was most probably always meant to return a string.
> Yes, Lisp code that causes it to return some other object is
> probably wrong.  However, the change that allowed this was
> introduced 19 years ago; who knows what code out there actually
> uses this loophole? If there is such code, why would we want to
> break it?  To what end? And if no code uses this loophole, why
> do we care that it exists?
> 
> IOW, thing-at-point no longer has any known bugs, and we are talking
> about forcibly breaking a use case that does no harm to us, and can
> only happen if someone abuses the 'thing-at-point' property, which
> would make it that someone's bug/misfeature, for them to fix.
> 
> So why would we want to make such a change?  What am I missing?

FWIW, I agree with you here, in general.

(I do not agree that thingatpt no longer has any known bugs,
however.  See bug #9300, which is a very important bug, to me.)

On the other hand, I'm pretty sure that some Emacs Dev deciders
have previously proclaimed that it is wrong for someone to exploit
this "loophole" and thus have `t-a-p' return something other than
a string.  And, as Tino points out, the doc says clearly that it
returns a string - no ifs, ands, or buts about that.

So yes, enforcing returning a string would be an incompatible
change.  But it would (apparently) do what Emacs Dev has said the
function should do, and it would do what the doc says it does
((elisp) `Buffer Contents').

Yes, deciding to enforce returning a string is outside the error
that was reported in this bug report.  On the other hand, the bug
title is precisely, explicitly this question we are discussing now:
Should `t-a-p' return a string?

I can work with this either way.  Long ago, I adapted my own code
to fit the prescription that `t-a-p' must return a string.  But I
guess I could make an incompatible change to my code, to once again
realign it with allowing a non-string return value.

My preference, at least so far, would be for us to do the following:

1. Enforce a string return value, in the way suggested.

2. CLEARLY point out, in the high-level doc, that returning a
   THING at point can mean two different things:

   * For `thing-at-point' it means return text (a string) that
     names/represents a THING.

   * For `form-at-point' and its callers (e.g., `symbol-at-point',
     `list-at-point', `sexp-at-point', `number-at-point'), it
     means return a THING, not its name.  That is, it returns an
     Emacs-Lisp entity - any kind of value that Lisp can return.

If we do NOT go down this road, but we instead stick with what is
there now (i.e., we do not enforce a string value for `t-a-p')
then I think it is imperative that we point out, in the doc,
that `t-a-p', like `form-at-point' and its callers, can return
a Lisp THING of any kind OR a string naming such a THING, and
that the former case is realized via property `thing-at-point'
on the THING-argument symbol.

Being clear and explicit about what it does and how will help
avoid the kinds of ambiguity that have plagued this function
for a long time now.