From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas =?UTF-8?Q?R=C3=B6hler?= 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 20:38:07 +0200 Message-ID: <414ccabd-9198-6ae0-594c-e6014e85de75@easy-emacs.de> References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1466447762 6319 80.91.229.3 (20 Jun 2016 18:36:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 18:36:02 +0000 (UTC) To: 9300@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 20 20:35:50 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 1bF430-0002bH-RO for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 20:35:47 +0200 Original-Received: from localhost ([::1]:45627 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF430-0007Nr-3D for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 14:35:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF42N-0006u4-Df for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:35:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF42J-0007cY-Bw for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:35:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF42J-0007cO-8J for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:35:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bF42H-0008Hd-UJ for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:35:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jun 2016 18:35: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: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.146644764331773 (code B ref -1); Mon, 20 Jun 2016 18:35:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 20 Jun 2016 18:34:03 +0000 Original-Received: from localhost ([127.0.0.1]:47990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF41K-0008GP-QL for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:34:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF41J-0008Fv-UL for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:34:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF41D-0007Tg-5F for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:33:56 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:33558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF41D-0007TR-22 for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:33:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF41A-000512-GV for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:33:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF415-0007SE-G4 for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:33:51 -0400 Original-Received: from mout.kundenserver.de ([217.72.192.73]:57207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF415-0007S3-5H for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:33:47 -0400 Original-Received: from [192.168.178.35] ([77.12.77.196]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0MLyNI-1bILo50SNQ-007iSj for ; Mon, 20 Jun 2016 20:33:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 In-Reply-To: <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> X-Provags-ID: V03:K0:aAcdx6G0h7RwQ3yXugvBhEvBEnikNls5b/NMwpPtQSfwL7RQgfx i+23UG9/l4taZuO8xd6igNpXzRkqtxVK+3dgcLsqqK4zGnwPzexcslMz+xL2Myoh5TQapXO ipHcFK8Huv9WPhE7syqhltAtru2/XJf1Zzg/2W05wfDY6ZBUfbHtSqjaOW2+OKuTsyDiZpv G64JXP/aT/j0x4Q2r3okw== X-UI-Out-Filterresults: notjunk:1;V01:K0:XJ3GNbZRY+A=:ivKnUd8tHNzbAB1+qm7Jho 7UMnsQEVJJCFdxeZS/MiLWMiWvbqWuBYS0/ohTq05be1pFQK6MDCKAV5akNe+xm7o1woAqm2j 1B4tyWlVkgo6Yfoq6zsv/4gBEMNcDH7suTqcMhaQzcMR08iXa0qiHmt+QZV0BYIJJz+DSQAkE AFnpgU0SCo45LDv27aq+uNVlTrhaZIwOwfvw/5gZsRcPufX1RMXuOiiOIU8YvxS/SQyIWKxwp BdgdJLjyp8a0iEdgb8AUWSN5P68y5KpmQgX7KX5VY7MrN6O2pMJ5C9wYu5787CuunyTgxnT6u 3GlCIiIzW3CvBYUtQX677CzF4FCEZxEuMjdN/rIGtKuWPUM8hAd71M+ISfKvJx8FILb8aXvd7 ewcPGTOaimw5gap1poyagYRT83LTiHMgdE9Yo7qG1bwy8qY/Wfo0Nm0e1BqMRZA1868wXdKMi AFAM2XZSLQ4W8lOBb6lKDKvnNARyZAYSVQy/hF/4JpYohUSma0VkVpvAD4hupVhZI9lyVbrWA zzwrXW8rrI6QmvIkLn4gfqdc5zofl15aDIPA3NLO9unLkc9+ADWidkXR7XEhv7ytkV/qRFwQE HEbKMJH47jEF0ZPkmRve8GE/ZdjZWxIle7zaZ/MhjJown9iCSh57u6+SYvIKSRk95SB0KQxKj f8L6Q4q5c3a21R5EB7Tx+lXJPGDDfr2AlplrRwAUb7DrkNqfM+v8+sOBAzfICOaaECFbt69B5 CJv7TCYZRYnlCq+B X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:119849 Archived-At: 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