From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Date: Mon, 20 Jun 2016 10:50:27 -0700 (PDT) Message-ID: <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com>> <<8337o79arh.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1466445128 29355 80.91.229.3 (20 Jun 2016 17:52:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 17:52:08 +0000 (UTC) Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii , Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 20 19:51:54 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bF3M0-0003TD-5R for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 19:51:20 +0200 Original-Received: from localhost ([::1]:45388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF3Lw-0003nk-9R for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 13:51:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF3Ln-0003lj-7x for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 13:51:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF3Li-0005Er-9o for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 13:51:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF3Li-0005Ek-6g for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 13:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bF3Lh-0007IE-SN for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 13:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jun 2016 17:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9300 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9300-submit@debbugs.gnu.org id=B9300.146644503728004 (code B ref 9300); Mon, 20 Jun 2016 17:51:01 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 17:50:37 +0000 Original-Received: from localhost ([127.0.0.1]:47985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF3LJ-0007Hc-5v for submit@debbugs.gnu.org; Mon, 20 Jun 2016 13:50:37 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:34140) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF3LH-0007HO-1A for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 13:50:35 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5KHoSUo021511 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 17:50:28 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u5KHoS7p013487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 17:50:28 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u5KHoRvp008962; Mon, 20 Jun 2016 17:50:27 GMT In-Reply-To: <<8337o79arh.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:119847 Archived-At: > > * 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.