[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#21391: 24.5; `thing-at-point' should return a string
Date: Thu, 10 Nov 2016 18:08:49 +0200

> Cc: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> 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

> > 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]