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: Tue, 23 Feb 2016 17:31:02 -0800 (PST) Message-ID: <6635cd58-2d42-46fe-85b4-287f1e0eb05d@default> References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> <56CC32CD.5050906@yandex.ru> <27990eb0-3d4e-62c7-257d-7ea7a8204e2d@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 1456277546 6861 80.91.229.3 (24 Feb 2016 01:32:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Feb 2016 01:32: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 Wed Feb 24 02:32:12 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 1aYOJG-0004US-UR for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Feb 2016 02:32:11 +0100 Original-Received: from localhost ([::1]:60946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYOJF-0001Za-Uf for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Feb 2016 20:32:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYOJC-0001ZE-G1 for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 20:32:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYOJ8-0005a9-D6 for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 20:32:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYOJ8-0005a5-9T for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 20:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aYOJ8-0006c8-5O for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 20:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Feb 2016 01:32:02 +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.145627747523317 (code B ref 9300); Wed, 24 Feb 2016 01:32:02 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 24 Feb 2016 01:31:15 +0000 Original-Received: from localhost ([127.0.0.1]:41860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYOIN-00063c-8G for submit@debbugs.gnu.org; Tue, 23 Feb 2016 20:31:15 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18691) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYOIM-0005yZ-73 for 9300@debbugs.gnu.org; Tue, 23 Feb 2016 20:31:14 -0500 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 u1O1V7vF027113 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2016 01:31:08 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1O1V6pZ017512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 01:31:07 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1O1V60R025685; Wed, 24 Feb 2016 01:31:06 GMT In-Reply-To: <27990eb0-3d4e-62c7-257d-7ea7a8204e2d@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:113626 Archived-At: > > Yes, it should return nil, as there is NO symbol at point. >=20 > If we ask the users, I'm guessing we'll get mixed answers on that, at > least as a result of this long-standing thing-at-point behavior. You might get opinions, but the fact is that there is no thing at point in that case. "At point" can only mean, since point is between characters, either before point or after point. It cannot mean both. Not and keep a possibility of recursive/iterative use. Moving forward over a thing puts point after the thing. It does not keep point on/at the thing. The design must pick one or the other meaning of "at": a character that belongs to the THING at point is either after or before point. It cannot reasonably be both. IMO, and all of the code confirms this (apart from this bug): "at" in "thing at point" means after point, not before point. > > It is your expectation that is wrong. There are plenty of uses > > of thing-at-point that go far beyond just looking for a default > > value of a name near point or trying to complete a name before > > (not at) point. >=20 > What I'm saying is, "fixing" it will most likely break code in the wild. > Not just mine. The fix to your code and theirs is trivial. Bit if you must, rename the current, bugged implementation of `bounds-of-thing-at-point' to `bounds-of-thing-at-or-after-point'. Tell such folks to use that. Likewise, add `thing-at-or-after-point', if necessary, for any code that current depends on the broken `thing-at-point'. If you must, do that plus deprecate the (perfectly good, but not for this broken code) name `bounds-of-thing-at-point', so any such 3rd-party code makes the change. And add a function `bounds-of-thing-at-point-strict' that does what `bounds-of-thing-at-point' should do (=3D the bug fix). Change the Emacs code that uses the broken `bounds-of-thing-at-point' to use `bounds-of-thing-at-point-strict'. IOW, wean any code from the broken implementation and use the fixed implementation. This is if you are convinced that there are zillions of uses of the bugged `bounds-of-thing-at-point' that depend on the bugged behavior. I'm not convinced of that. I'd say bite the bullet: fix the bug properly, and when anyone complains tell them to use `bounds-of-thing-at-or-after-point' 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. > > Those other uses include the need to test whether or not there > > IS a given THING at point. The design itself depends on this > > difference: Is there a THING at point or not? >=20 > They can call (bounds-of-thing-at-point 'foo), and then compare > the cdr with the value of point. You are missing the point. I won't repeat myself. See what I wrote about use cases. See the code I referenced, if needed. > >>> This is the design of the thingatpt code, and the reason why > >>> `<=3D' instead of `<' is a bug: > >>> > >>> the function that is (get THING 'end-op) moves PAST the THING, > >>> so that point is not on the THING. This is true generally, no > >>> matter the type of THING. > >> > >> That's not a quote from thingatpt.el. > > > > It is nevertheless the design (intention), clear from the code. >=20 > I'm not so clear on that. That much is clear. > The following comment tells me the opposite > (the position where a substring ends is normally the one _after_ its > last character): >=20 > ;; Try a second time, moving backward first and then forward, > ;; so that we can find a thing that ends at ORIG. ORIG is the original position. A thing that ends at that position is at point. A thing that ends before that position is not a thing at point. Look at `goto-char' or any other char-counting functions. If you move point "to" character 2, point =3D 2. The char "at" point is the char after point - point is before the char that has the same number as point. When point =3D 2 the cursor position (aka point) is between chars 1 and 2, and we say point is "at" (or "looking at") char 2. > If we didn't need to be able to find a thing that ends just before > point, Before is not at (=3D after). Ends at ORIG does not mean ends before ORIG. > I don't think the implementation would need the "Try a second > time" branch at all: when point if before the last character of a > symbol, (forward-symbol) still works. Believe me, I've walked through that particular code a hundred times, in the debugger and without. The code you are referring to is needed, and it is not about finding a thing that ends before point. But I think you either try to see or you don't. I cannot make you see.