[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thing-at-point: inconsistent behaviour?
From: |
Raffaele Ricciardi |
Subject: |
Re: thing-at-point: inconsistent behaviour? |
Date: |
Thu, 16 Aug 2012 18:12:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 |
On 08/16/2012 05:24 PM, Andreas Röhler wrote:
> Am 16.08.2012 17:48, schrieb Barry Margolin:
>> In article <mailman.7107.1345117968.855.help-gnu-emacs@gnu.org>,
>> Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>>
>>> Am 15.08.2012 21:00, schrieb Raffaele Ricciardi:
>>>> On 08/15/2012 07:34 PM, Barry Margolin wrote:
>>>> > In article <a926tjFeslU1@mid.individual.net>,
>>>> > Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:
>>>> >
>>>> >> Hello there,
>>>> >>
>>>> >> the documentation of `thing-at-point' states that such function
>>>> returns
>>>> >> "the
>>>> >> thing around or next to point". This is not the case with either
>>>> >> (thing-at-point
>>>> >> 'symbol) or (thing-at-point 'sexp), for they both may return
>>>> the thing
>>>> >> before
>>>> >> point. Try it with the following snippet (! symbolizes the
>>>> point):
>>>> >
>>>> > Doesn't "next to" include both immediately before and
>>>> immediately after?
>>>>
>>>> I stand corrected after having consulted a dictionary. Then it is
>>>> (thing-at-point 'list) that is misbehaving.
>>>>
>>>
>>>
>>> hmm, IMHO you was right. Here is the code
>>>
>>> (defun symbol-at-point ()
>>> "Return the symbol at point, or nil if none is found."
>>> (let ((thing (thing-at-point 'symbol)))
>>> (if thing (intern thing))))
>>>
>>> last line don't return the thing as delivered by thing-at-point but the
>>> result of (intern thing)
>>>
>>> that way breaking consistency.
>>
>> That function has nothing to do with the problem he's reporting. It's
>> just an extra utility function that makes use of thing-at-point to
>> return something that may be useful in certain situations.
>>
>
> okay, as it happens it's for years in my mind: that symbol-at-point
> breaks consistency.
>
> Another approach to give the reasons:
>
> IMO basically two ways of returns are feasible by such a thing-at-point
> library
>
> - deliver objects from editing perspective, i.e as buffer-substrings
> - deliver objects for use in programs
When you are looking for a buffer substring, you call
`bounds-of-thing-at-point'; when you are looking for a string result,
you call
`thing-at-point'; when you want the result as a sexp, you call the
specialized
function.
> Not to expect is changing the computers internal state already when
> picking an object by thing-at-point.
> That's what is done by "intern" however.
Indeed this is an undesirable side effect of `symbol-at-point' calling
`intern'. Could `intern' be replaced with `make-symbol'?
- thing-at-point: inconsistent behaviour?, Raffaele Ricciardi, 2012/08/15
- Re: thing-at-point: inconsistent behaviour?, Barry Margolin, 2012/08/15
- RE: thing-at-point: inconsistent behaviour?, Drew Adams, 2012/08/15
- Re: thing-at-point: inconsistent behaviour?, Raffaele Ricciardi, 2012/08/15
- Re: thing-at-point: inconsistent behaviour?, Andreas Röhler, 2012/08/16
- Message not available
- Re: thing-at-point: inconsistent behaviour?, Barry Margolin, 2012/08/16
- Re: thing-at-point: inconsistent behaviour?, Andreas Röhler, 2012/08/16
- Message not available
- Re: thing-at-point: inconsistent behaviour?,
Raffaele Ricciardi <=
- Re: thing-at-point: inconsistent behaviour?, Barry Margolin, 2012/08/16
- RE: thing-at-point: inconsistent behaviour?, Drew Adams, 2012/08/16
- Message not available
- Re: thing-at-point: inconsistent behaviour?, Barry Margolin, 2012/08/16
- RE: thing-at-point: inconsistent behaviour?, Drew Adams, 2012/08/17
- Message not available
- Re: thing-at-point: inconsistent behaviour?, Raffaele Ricciardi, 2012/08/17
- RE: thing-at-point: inconsistent behaviour?, Drew Adams, 2012/08/19