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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 10 Nov 2016 18:08:49 +0200

> Cc: [email-masked], [email-masked]
> From: Dmitry Gutov <[email-masked]>
> Date: Thu, 10 Nov 2016 01:30:20 +0200
> 
> See the attached patch.
> 
> Or to take a step further, we might want to deprecate the 
> `thing-at-point' property, and recommend to only use the 
> `bounds-of-thing-at-point' property. This way, we get the string-ness 
> guarantee automatically, and the bounds-of-thing-at-point function will 
> work for all things (it currently fails for `number').
> 
> >>> 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?
> >>
> >> To make thing-at-point behavior more consistent.
> >
> > It is consistent now.
> 
> Put point on a number. Number is a sexp. Not all sexps are strings.
> 
> (thing-at-point 'number) => 123
> (thing-at-point 'sexp) => "123"
> 
> That doesn't looks consistent to me.

There's a tension here between consistency and backward compatibility.
And since this function was "inconsistent" for a very long time, I'm
not sure losing backward compatibility can be justified by consistency
at this point.

We'd also lose something else: some Lisp objects can be printed, but
their printed representation cannot be read back.  So for some
objects, requiring thing-at-point to return a string would lose
information.

> > The only way to make it inconsistent is to have
> > a 'thing-at-point' property that violates that, but we never do that
> > in Emacs proper, so if someone else does that, it would be their bug.
> 
> number's `thing-at-point' property is not like the others.

Right, I succeeded to forget that since the beginning of this thread.