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 09:00:27 -0800 (PST) Message-ID: 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> <76b6983a-da47-48da-ba9b-20ede56ed691@default> <74937597-35e0-4ee9-10dd-cc33eedfb084@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 1456506165 31963 80.91.229.3 (26 Feb 2016 17:02:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 17:02:45 +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 18:02:32 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 1aZLmh-0006S9-VV for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 18:02:32 +0100 Original-Received: from localhost ([::1]:51225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZLmg-00013z-PV for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 12:02:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZLlK-0007vJ-4M for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 12:01:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZLlG-0002m7-U5 for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 12:01:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZLlG-0002m0-RD for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 12:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZLlG-0000PK-Ih for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 12:01: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: Fri, 26 Feb 2016 17:01: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.14565060491536 (code B ref 9300); Fri, 26 Feb 2016 17:01:02 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 17:00:49 +0000 Original-Received: from localhost ([127.0.0.1]:47845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZLl2-0000Oi-T3 for submit@debbugs.gnu.org; Fri, 26 Feb 2016 12:00:49 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:30007) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZLl1-0000OW-Sx for 9300@debbugs.gnu.org; Fri, 26 Feb 2016 12:00:48 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1QH0fRP013073 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Feb 2016 17:00:41 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1QH0d41028880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 17:00:40 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1QH0XwZ006104; Fri, 26 Feb 2016 17:00:38 GMT In-Reply-To: <74937597-35e0-4ee9-10dd-cc33eedfb084@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: userv0022.oracle.com [156.151.31.74] 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:113899 Archived-At: > > 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. >=20 > I'd be interested in a patch. Especially if it's orthogonal > (as it should be) to whatever we decide in this bug. I'm interested in _this_ bug being fixed. Bugs for individual THINGs are much more minor. This bug affects *all* THINGs - the basic behavior of thing at point. This about the basic behavior. But this is a bug that someone will not notice if their only use of thingatpt.el is, as in your case, to grab some text near point for completion or for use as a default value. That is why this bug has gone unnoticed and unreported. Such uses underestimate the power of thingatpt.el and misunderstand what it is about. It is about more than trying to maximize the possibility of getting something near point. It is important that the functions can actually tell you, accurately, _whether_ there is a THING at point. If you are looking to grab something near point then you don't care about this. But that's not all of what thingatpt.el is about. If you want to get a THING that is at OR NEAR point then you should use code that does that (I have such *_nearest_* code, and you are beginning to work on some too, it seems). But thing-at-point (and bounds) should not be corrupted to return a THING instead of nil when there is no THING at point. That is, alas, currently the case. But as I said, I do not need this bug fix for myself. I use my own code, which does not have the bug. I had to fix it long ago, to get reasonable behavior for navigating among and parsing multiple THING occurrences. The boundary between one THING and another, and between a THING and non-THING needs to be defined in a way that is consistent and usable in a general way. That's not the case if a THING _before_ point is returned when you try to test for a THING at point. Likewise for users of my libraries. I let them know that the Isearch+ and Icicles features that act on successive THINGs in a buffer will not work for some THINGs if they use only vanilla thingatpt.el. For consistent and reliable use they will need to also load thingatpt+.el. (My libraries do not _require_ it.) I occasionally get a bug report to which I need to reply that thingatpt.el has this bug and advise them to use thingatpt+.el for things to work. For them to take advantage of the code that really uses THINGs for more than simply grabbing text near point to use as a default value or for completion, this bug needs to be fixed. Or they need to use thingatpt+.el. I would prefer that they be able to get the fixed behavior from vanilla Emacs, but if not, no problem for me. I filed the bug report for Emacs, not for me. But you know that.