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 16:34:46 -0700 (PDT) Message-ID: References: << <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com>>> <<<8337o79arh.fsf@gnu.org>>> <<0e2c9c67-12a2-4712-92d2-e3c204f46838@default>> <<83twgn7hjx.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 1466465740 31728 80.91.229.3 (20 Jun 2016 23:35:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 23:35:40 +0000 (UTC) Cc: f92capac@gmail.com, tino.calancha@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 21 01:35:24 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 1bF8iw-0007LZ-8f for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Jun 2016 01:35:22 +0200 Original-Received: from localhost ([::1]:47077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF8iv-0005Zl-Hk for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 19:35:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF8ik-0005We-LM for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 19:35:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF8ic-0001eE-0Q for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 19:35:10 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF8ib-0001eA-T8 for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 19:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bF8ib-0006lZ-Ok for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 19:35: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 23: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: Original-Received: via spool by 9300-submit@debbugs.gnu.org id=B9300.146646569925998 (code B ref 9300); Mon, 20 Jun 2016 23:35:01 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 23:34:59 +0000 Original-Received: from localhost ([127.0.0.1]:48154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF8iZ-0006lG-8W for submit@debbugs.gnu.org; Mon, 20 Jun 2016 19:34:59 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:45414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF8iX-0006l0-DZ for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 19:34:57 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5KNYoJj008594 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 23:34:50 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u5KNYn9Q018556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 23:34:49 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u5KNYkh2014889; Mon, 20 Jun 2016 23:34:47 GMT In-Reply-To: <<83twgn7hjx.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: userv0021.oracle.com [156.151.31.71] 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:119855 Archived-At: > > > 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. >=20 > That's immaterial. It is being used in many places, and it's > obviously useful. It is not being used in _any_ place where it matters whether there is a thing just before point but not at point. It cannot be used in such a place because of this bug. Can you point to such a use? "It is obviously useful" ONLY for cases where you don't really care _whether_ there is a thing at point and you only want to get a thing at point or at point-minus-one - you prefer to get a thing rather than nil, even if the thing is not quite at point. Sure, such behavior can be useful if that's what one wants, and "it is being used in many places" - to just grab something to use as a default value. But it is not always grabbing a thing at point. Just rename this grab-for-defaulting function: "*-near-point" or "*-at-or-just-before-point". It is not _at_ point. > Somewhere in this long discussion there was a suggestion to > add new functions that behave like you want. It is not about what I want. It is what "at point" means. At_point_or_at_point_minus_one is not the same thing as at_point. Currently the behavior is the former, not the latter. That most people don't notice or care about that is immaterial. I already provided a correct implementation for at-point behavior. And I already provided an implementation for near-point behavior, albeit a better one than just at_point_or_at_point_minus_one. For the latter, you already have the current, broken implementation - just rename it "*-near-point*". > I suggest to invest energy in that direction, instead of more > bikeshedding. I'm not bikeshedding. And I'll thank you to drop such a characterization. This is a real bug. That you don't recognize it is too bad. I already invested energy in providing the function needed, i.e., in fixing, as well as reporting, this bug. And I (and others) have been using the fix for decades. I pointed you to code that provides not only the needed behavior for `bounds-of-thing-at-point' but also other improvements for thingatpt.el. If you are uninterested, that's too bad. > That way, everyone is happy, and you even get to prove you > are right, if at some future point in time we will find that > most applications switched to the new APIs. Unlike some, I'm not really interested in proving I'm right. But if you are interested, the proof is that you cannot use the current code to distinguish whether there is a thing at point from whether there is a thing at point-minus-one. Can you point to a single use of thingatpt.el code that does more than just use a thing at-or-just-before point as a default value? Can you point to a single use that really cares about whether there actually is a thing at point, and is not just trying to grab a thing near point? A use where a nil value is actually useful and taken into account as more than simply a lack of a default value? I don't think you'll find any (other than uses of my code). This bug prevents using thing-at-point that way (general, precise). It confounds a thing at point with a thing at point-minus-one. I have what I need, in my own code. You've heard in this bug thread from a couple other users as well. Lousy bikeshedders too, no doubt. But one of them has written his own code that builds on thingatpt.el, and has clearly been interested in thing-at-point and knowledgable about it for years. The other has contributed several uncontroversial and non-bikeshed bug fixes to Emacs recently. You will not hear from lots of others about this, naturally. If one does not try to use thing-at-point to actually see whether there is a thing at point then one will not even notice this bug. But if the bug is fixed then all kinds of possibilities open up for handling multiple occurrences of a thing etc., possibilities that are precluded today, simply because the code cannot tell the difference between there being a thing at point and there being a thing at point-minus-one. Dommage. And if you fix this bug what happens to those who are using the code today only to get a default value? If point is after a thing, and there is NO thing at point, then they will get no default value. If they complain about that in some context, you have only to point them to your new `*-near-point' function for the behavior they think they miss. And for any occurrences in Emacs code where you think that is the behavior you want, just use the new function. It's pretty simple, really. If you want to improve Emacs for thing-at-point, apply the one-off-bug fix and also offer another function that maximizes returning a thing rather than precisely getting a thing at point or returning nil if there is none there. My suggestion for the `*-near-point' function would be to do something like what I did, letting users and code control how near "near" is in any given context. But if you want to keep it rudimentary, where "near" means only at point or at point-minus-one, then just rename the code you have now to `*-near-point'.