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: Thu, 25 Feb 2016 17:44:07 -0800 (PST) Message-ID: <05f0b24b-1a52-4fa4-9f22-f34f5ed33556@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> 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 1456451131 11913 80.91.229.3 (26 Feb 2016 01:45:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 01:45:31 +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 02:45:17 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 1aZ7Sy-0003a3-QX for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 02:45:13 +0100 Original-Received: from localhost ([::1]:46808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ7Sx-0004Fo-Rl for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Feb 2016 20:45:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ7St-0004E6-Md for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:45:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZ7So-00020u-Lj for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:45:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49371) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ7So-00020q-IE for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZ7So-0003Tt-B7 for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:45: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 01:45: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.145645105813321 (code B ref 9300); Fri, 26 Feb 2016 01:45:02 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 01:44:18 +0000 Original-Received: from localhost ([127.0.0.1]:46498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZ7S5-0003Sn-OZ for submit@debbugs.gnu.org; Thu, 25 Feb 2016 20:44:17 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42923) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZ7S4-0003Sa-Ao for 9300@debbugs.gnu.org; Thu, 25 Feb 2016 20:44:16 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1Q1i9jR010788 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Feb 2016 01:44:10 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1Q1i9Gd016002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 01:44:09 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1Q1i8hN001541; Fri, 26 Feb 2016 01:44:08 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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:113825 Archived-At: > > The fix to your code and theirs is trivial. >=20 > Where's that "think of the poor users" call of yours that > accompanies any breaking change in Emacs? Users don't like broken code. > We can only fix code inside Emacs. And when we do, 3rd-party code sometimes has to adjust. I'm forced to do that all the time - and not for bug fixes, usually. This fix will give all users better, and consistent behavior. > > Bit if you must, rename the current, bugged implementation of > > `bounds-of-thing-at-point' to `bounds-of-thing-at-or-after-point'. I meant ...-or-before-... not ...-or-after-... > A rename will break third-party code just as well. The proper fix for such bad 3rd-party code (it never should have depended on a bug that nil is not returned when there is no thing at point) is to move to the position where it _really_ wants to look for a thing. Such code is typically just looking for a thing near point, for completion or to use as a default value. But we _could_ provide a function that finds the thing at or just before point. If you don't want to provide such a function, so much the better. > > Tell such folks to use that. Likewise, add `thing-at-or-after- > > point', (Again, I meant ...-or-before-... not ...-or-after-...) > > if necessary, for any code that current depends on the broken > > `thing-at-point'. >=20 > Won't be usable in packages targeting older versions. Right. Like all 3rd-party code, it will use (if (fboundp...)...). 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. That's what always should have done, and that has always worked (and hopefully always will). > > 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'. >=20 > We can add bounds-of-thing-at-point-strict even without changing the > existing function. Patch welcome, I think. It's the same patch. The proper name for it is `bounds-of-thing-at-point'. But if you are stubborn then go for `bounds-of-thing-at-point-strict'. But be sure to use it everywhere in the Emacs code in place of `bounds-of-thing-at-point' - that's the fix. > > 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. >=20 > Maybe there aren't too many. Will you do the research on this? Nope. Will you? Does anyone need to? 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. > > 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' (Again, I meant ...-or-before-... not ...-or-after-...) > > 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. >=20 > 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? That's the behavior you get today, and apparently the behavior you still want: ask for a thing that is either at point or one char before point. > Yup. But when we say "word X ends at position P", P is after the > last character of X, not before. >=20 > > Before is not at (=3D after). Ends at ORIG does not mean ends > > before ORIG. >=20 > 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. There is a reason for this behavior. It is what's needed when you use `thing-at-point' in combination (e.g. repetitively). I pointed you to code that does this. And yes, it needs to work for all types of THINGs, including, yes, symbols (words, names,...). > > But I think you either try to see or you don't. I cannot make > > you see. >=20 > That's a very zen position for someone who just wrote a 2.5 screen > email. 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. I don't need this bug fix for my own code. Just trying to do a good deed for Emacs and its users. I fixed this long ago for myself, and I make heavy use of the fix. You're not interested in fixing this in Emacs. So be it. You said at the outset: Your reasoning seems valid, however by now this behavior is ingrained into my expectations of how thing-at-point should behave. 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. Sheesh.