From: "Andreas Röhler" <andreas.roehler@easy-emacs.de>
To: 9300@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 [thread overview]
Message-ID: <414ccabd-9198-6ae0-594c-e6014e85de75@easy-emacs.de> (raw)
In-Reply-To: <0e2c9c67-12a2-4712-92d2-e3c204f46838@default>
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
next prev parent reply other threads:[~2016-06-20 18:38 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-14 22:36 bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Drew Adams
2016-06-20 9:21 ` Tino Calancha
2016-06-20 12:53 ` Dmitry Gutov
2016-06-20 13:11 ` Tino Calancha
2016-06-20 14:48 ` Eli Zaretskii
2016-06-21 3:01 ` Tino Calancha
[not found] ` <<8337o79arh.fsf@gnu.org>
2016-06-20 17:50 ` Drew Adams
2016-06-20 18:38 ` Andreas Röhler [this message]
2016-06-20 20:04 ` Eli Zaretskii
2016-06-21 6:14 ` Andreas Röhler
2016-06-21 12:50 ` Eli Zaretskii
2016-06-21 13:07 ` Andreas Röhler
2016-06-21 15:13 ` Eli Zaretskii
2016-06-21 13:31 ` Drew Adams
2016-06-21 15:16 ` Eli Zaretskii
2016-06-21 13:25 ` Drew Adams
[not found] ` <<<8337o79arh.fsf@gnu.org>
[not found] ` <<0e2c9c67-12a2-4712-92d2-e3c204f46838@default>
[not found] ` <<83twgn7hjx.fsf@gnu.org>
2016-06-20 23:34 ` Drew Adams
2016-06-20 23:59 ` Noam Postavsky
2016-06-21 0:47 ` Drew Adams
[not found] <<B1052724B2D446C59E233FC1BD437723@us.oracle.com>
2015-07-29 1:44 ` Drew Adams
2016-01-15 13:33 ` Drew Adams
2016-02-23 1:01 ` Dmitry Gutov
2016-02-23 6:37 ` Drew Adams
2016-02-23 7:59 ` Andreas Röhler
2016-02-23 10:22 ` Dmitry Gutov
2016-02-23 16:15 ` Drew Adams
2016-02-24 0:52 ` Dmitry Gutov
2016-02-24 1:31 ` Drew Adams
2016-02-26 1:03 ` Dmitry Gutov
2016-02-26 1:44 ` Drew Adams
2016-02-26 10:15 ` Dmitry Gutov
2016-02-26 14:39 ` Drew Adams
2016-02-26 15:25 ` Dmitry Gutov
2016-02-26 17:00 ` Drew Adams
2022-04-28 11:24 ` Lars Ingebrigtsen
2022-04-28 15:49 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=414ccabd-9198-6ae0-594c-e6014e85de75@easy-emacs.de \
--to=andreas.roehler@easy-emacs.de \
--cc=9300@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).