GNU bug report logs - #9300
24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING

Previous Next

Full log

Message #41 received at 9300 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Drew Adams <drew.adams <at> oracle.com>, 9300 <at> debbugs.gnu.org
Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil
 when just after THING
Date: Fri, 26 Feb 2016 12:15:45 +0200

On 02/26/2016 03:44 AM, Drew Adams wrote:

> But the proper fix for 3rd-party code, mentioned above, does not
> have any such problem.  It should look for a thing at (1- (point))
> if it wants to get a thing that might be just before point but not
> at point.

If the thing _begins_ at point, and the third-party code in question 
calls (save-excursion (forward-char -1) (thing-at-point 'foo)), they 
will get nil.

>> Maybe there aren't too many. Will you do the research on this?
>
> Does anyone need to?

I imagine so.

> You're the one who
> mentioned that your code depends on checking for a thing at the
> wrong position in order to get a thing at point-minus-one.  And
> you mentioned an Eclipse function that acts similarly.  That's two.

I never mentioned anything Eclipse-related in this bug.

>>> if they really want the bugged behavior.  Better: tell them
>>> to use the fixed `bounds-of-thing-at-point' after backing up
>>> so point is actually on the THING instead of after it.
>>
>> Any such client would be forced to call bounds-of-thing-at-point-
>> strict twice. Which is not particularly ideal.
>
> Not at all.  Why do you say that?

See above.

>> Think of the semantics of `match-end', or the last argument of
>> `substring'.
>
> Think of all the other uses of thing-at-point, and the other THINGs
> it finds and where it finds them.
>
> Type (foo bar) at top level, and put point after the ).
> M-: (thing-at-point 'list)
> What do you get?  id it give you "(foo bar)"?  Or did it give
> you nil?  There is no list at point.  Is this a bug?  No; it's TRT.

If the list is at the end of the buffer, it gives me an empty string, or 
a string of spaces. So yeah, this particular "thing" seems bugged.

> Why don't you present a valid (in your sense) configuration
>> that a bounds-of-thing-at-point implementation without the "else"
>> branch will return nil in?
>
> OK, I give up.

Because there is no such example.

> It's clearly not about your being unconvinced that the fix is correct.
> It's about your not wanting to give up your ingrained expectations
> of the incorrect behavior.

Not just mine. I believe I have demonstrated that the code has been 
written with exactly this expectation in mind. And stayed like that for 
decades.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.