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

View this message in rfc822 format

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: 9300 <at> debbugs.gnu.org
Subject: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING
Date: Mon, 20 Jun 2016 20:38:07 +0200

On 20.06.2016 19:50, Drew Adams wrote:
>>> * I agree with Drew that there is neither sexp nor list at point,
>>>     so i would expect I), II), III) and IV) returning nil.
> Tino agrees because he wants to make use of the difference between
> there being a THING at point and there being no THING at point but
> there being a THING at (1- (point)).
>
>> FWIW, I agree with Dmitry: this has been a de-facto behavior long
>> enough to consider it the correct one. If documentation is confusing
>> in that it says otherwise, we should fix the documentation.
> I couldn't disagree more.
>
> It is wrong to consider the current behavior "the correct one",
> regardless of how long it has been in place.  It is wrong because
> you cannot use it in a general and precise way.  It is just broken.
> It has been broken for a long time, but it is broken nevertheless.
>
> The proper thing to do is to:
>
>    1. Fix this bug.  It is a real bug.
>
>    2. Add a new function that provides the same behavior as the
>       broken behavior that is current, or similar.  And call it
>       "-near-point", not "-at-point".
>
> More precisely, for #2 the use case you cite is only to maximize
> grabbing a thing at or _near_ point.  In the case of the current
> code, that means at point or at (1- (point)).  If all you care
> about is grabbing something at either of those positions then the
> code works for you.  If you try to use it more generally, it is
> broken.  IOW, if you actually care about the difference between
> point and (1- (point)) then you are out of luck.
>
> A better, more general, near-point function looks farther from
> point, up to some caller-specified distance (horizontally and
> vertically).  That's the purpose, in my code, of variables
> `tap-near-point-x-distance' & `tap-near-point-y-distance' and
> function `tap-bounds-of-thing-nearest-point' (prefix `tap-' for
> library `thingatpt+.el').
>
> See the arguments given in the bug thread for why #1 is important -
> why `bounds-of-thing-at-point' should be fixed as indicated.
>
> It is important that one be able to use `bounds-of-thing-at-point'
> and `thing-at-point' in a way that is accurate, precise, and
> general, and not only to try to grab something that is near point.
>
> In particular, this matters when the functions are used
> programmatically to handle successive THINGs (of the same type)
> in a buffer or region.  For that, there needs to be a clean
> boundary between THING and no THING at a given position.  You
> need to be able to test whether there is actually a THING at
> point.
>
> I've spent a lot of time with this code, and with a fixed version
> of it, over the years.  My use cases go beyond just trying to come
> up with a default value for a minibuffer read.
>
> That doesn't seem to matter to those in charge here.  Too bad, but
> so be it.  I'll continue to use my code (`thingatpt+.el'), so not
> fixing this bug doesn't affect me much, directly.
>
> But it does affect me, and it affects others too.  For me, it
> means that other code, which makes use of this fix, must also
> conditionally handle the case where a user does not have
> `thingatpt+.el', even if the result is inadequate.
>
> I recommend to users of my code that makes use of thing-at-point
> features that they also use library `thingatpt+.el', but I try to
> let that other code have some semi-workable fallback behavior for
> the case where they do not use `thingatpt+.el'.
>
> So yes, this is an added (and unnecessary) burden for me and
> for users of my code.  But I've been dealing with it for years,
> so it's nothing new.
>
> The real loss, if you do not fix this bug, is for Emacs users who
> do not use `thingatpt+.el'.  They will be unable to do things with
> the `thing-at-point' code that they should be able to do, simply
> because it is broken at the end-of-thing boundary.
>
> But it has proven to be impossible to convince you to apply this
> simple fix.  So be it.
>
> I can only repeat that the proper solution is to fix this bug
> and to also give users a new function that does what you and they
> currently expect of `thing-at-point', for the use case of
> providing a default value for something: be able to grab a thing
> at or near point.
>
> `thingatpt+.el' has existed since 1996, yet you argue that even
> though the thingatpt.el code has this bug, it should not be
> fixed because users (or you) are used to it.
>
>    "Your reasoning seems valid, however by now this behavior is
>     ingrained into my expectations of how thing-at-point should
>     behave."
>
> Your expectations come from using the code only to grab a
> default value from the text.  You don't care about testing for
> a thing at point.  You want grabbing text to work even when
> there is no THING at point but there is a THING at (1- (point)).
>
> It would be simple enough to tell users to use the new function
> that gives you a thing at or _near_ point, if they want only to
> retrieve some text to use as a default value.
>
> You make changes all the time to Emacs code that necessitate
> 3rd-party code using (if (fboundp 'AAA) BBB CCC) tests.  This
> would be no different.  And the function names would be more
> correct: "-at-point" would really mean at point, and the
> behavior you expect would be properly named "-near-point".
>
> This bug has been declared "minor", but it is not - it makes
> the thing-at-point code unusable in a general and precise way.
> The fix, however, is trivial.  The pushback from you is major.
>
>
>

+1

Previous Next

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