bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Andreas Röhler
Subject: bug#21391: 24.5; `thing-at-point' should return a string
Date: Wed, 16 Nov 2016 14:49:43 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.4.0



On 14.11.2016 16:19, Drew Adams wrote:
Look at the start of thing-at-point implementation:

if (get thing 'thing-at-point)
    (funcall (get thing 'thing-at-point))

AFAIU an arbitrary function might  be stored here, no real
relation to thing-at-point at all.
ANY time you use a function as a parameter (passed as an
argument, obtained as the value of a variable, or picked up
in some other way, such as here) there is little or no control
over the nature of that function in the function that makes
use of it.  It is up to the code that provides the function
to provide an appropriate function (DTRT).

Next clause deals with buffer-substring - which is
thing-at-point about in my understanding.
Your understanding is partial, then.  Thing-at-point has
been, from the outset, about actual Lisp THINGS, not just
strings that name such things.  Yes, string-naming-a-thing
is a common use case - the most common, currently.  But it
is only part of the story.

And yes, buffer text is usually examined to come up with
the returned THING.  But the buffer text need not be
examined.  What is most significant is point - the buffer
position.  And even that could be ignored by the function
that comes up with an appropriate THING to return.

thingatpt.el is much more general, and offers many more
possibilities, than just grabbing some text at or near
point.

Agreed so far, understand that.
My point is to suggest a restriction here, making the use easier.

If a symbol might return an arbitrary thing doing arbitrary actions, why it should reside in this library? Beside this - upholding that in the core, a string is the result in any case first.

Follows functions which operate on this string, derive from its representation a number, intern it or whatever. For clarification IMO it would be better to separate these use-cases from the core-thing.

These use-cases are plain operations on strings, nothing special to thing-at-point.







reply via email to

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