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: Fri, 26 Feb 2016 06:39:32 -0800 (PST) Message-ID: <76b6983a-da47-48da-ba9b-20ede56ed691@default> References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> <56CC32CD.5050906@yandex.ru> <27990eb0-3d4e-62c7-257d-7ea7a8204e2d@yandex.ru> <6635cd58-2d42-46fe-85b4-287f1e0eb05d@default> <05f0b24b-1a52-4fa4-9f22-f34f5ed33556@default> <503db28a-d430-8a5d-a26d-e95890da58b9@yandex.ru> 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 1456497626 8504 80.91.229.3 (26 Feb 2016 14:40:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 14:40:26 +0000 (UTC) To: Dmitry Gutov , 9300@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 26 15:40:14 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 1aZJYz-0002MY-2C for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 15:40:13 +0100 Original-Received: from localhost ([::1]:50196 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZJYx-0006WL-9r for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 09:40:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZJYt-0006Um-Bs for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 09:40:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZJYo-0002OS-5C for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 09:40:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZJYo-0002OO-1e for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 09:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZJYn-0005EQ-Td for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 09:40:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Feb 2016 14:40: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.145649758420080 (code B ref 9300); Fri, 26 Feb 2016 14:40:01 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 14:39:44 +0000 Original-Received: from localhost ([127.0.0.1]:47066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZJYV-0005Do-Tp for submit@debbugs.gnu.org; Fri, 26 Feb 2016 09:39:44 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:47878) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZJYU-0005Db-1l for 9300@debbugs.gnu.org; Fri, 26 Feb 2016 09:39:42 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1QEdZLs003259 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Feb 2016 14:39:36 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1QEdYLH029429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 14:39:35 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1QEdY9c029588; Fri, 26 Feb 2016 14:39:34 GMT In-Reply-To: <503db28a-d430-8a5d-a26d-e95890da58b9@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113887 Archived-At: > > 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. >=20 > 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. So what? The point is that if code wants to get a thing at point OR a thing at point-minus-one, then that's exactly what it should check - which is, BTW, what the currently bugged code does. > > 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. >=20 > I never mentioned anything Eclipse-related in this bug. Sorry - "eclim". > >>> 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? >=20 > See above. No. Just use the current (bugged) implementation. It is a `bounds-of-thing-at-point-or-at-point-minus-one'. You might even provide a function that takes an other (e.g. optional) arg that is the other end of a range of positions over which to check whether there is a thing. Currently, you want the behavior of getting a thing at point or a thing that is point-minus-one. Add an argument to the new function that lets it return a thing that is at any of the positions between point and the new arg (a position). I only need to test for (and get) the thing at point (really at point). But other use cases might want what you want. > >> 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. >=20 > 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. I have much better-behaving list-at-point code. It's in the same file, if you are really interested. It always returns nil if the cursor is not on a list (there is no list at point), including when point is at eob. The crucial point is that THINGs that end *before* point are not *at* point. That's all. And this applies to all kinds of THINGs. Whether or not there are bugs for particular kinds of THINGs is something else, and those should be fixed individually. Comments come to mind, IIRC. I have several such fixes in my code. But the basic off-by-one bug (this bug) needs to be fixed, if we expect coherent thing-at-point behavior and flexible, repeatable use. > > 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. >=20 > Because there is no such example. Sigh. > > 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. >=20 > 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.