From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov 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 03:03:14 +0200 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1456448673 9172 80.91.229.3 (26 Feb 2016 01:04:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 01:04:33 +0000 (UTC) To: Drew Adams , 9300@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 26 02:04:19 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 1aZ6pM-00040Q-8I for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 02:04:16 +0100 Original-Received: from localhost ([::1]:46707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ6pI-0002uh-0I for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Feb 2016 20:04:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ6pE-0002uR-73 for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:04:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZ6p8-0000Xh-Jy for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:04:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ6p8-0000Xd-Fj for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZ6p8-0002Tx-52 for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2016 20:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Feb 2016 01:04: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.14564486049497 (code B ref 9300); Fri, 26 Feb 2016 01:04:02 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 01:03:24 +0000 Original-Received: from localhost ([127.0.0.1]:46469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZ6oW-0002T6-6v for submit@debbugs.gnu.org; Thu, 25 Feb 2016 20:03:24 -0500 Original-Received: from mail-wm0-f46.google.com ([74.125.82.46]:34699) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZ6oU-0002Ss-HA for 9300@debbugs.gnu.org; Thu, 25 Feb 2016 20:03:22 -0500 Original-Received: by mail-wm0-f46.google.com with SMTP id b205so53656067wmb.1 for <9300@debbugs.gnu.org>; Thu, 25 Feb 2016 17:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Ny1k40kzIrHHCzc4luLi6jxfoUiVi4oP/fRFHlC/+iQ=; b=mAQFJFQjL8ZVC5891/xxG3qgeDK70jAGOK1Dc4DFhdNi8PAFYe2Lzyn9BL6hB9gL9+ uoA5k1SRIDEtzflpiFTPC46cmwyxJLUJCn2cKc1SaYeqSY1RalZrAwrstE+x4BMqcaWZ hqgS3iMvQalEE9fG7hZhgKegYD1SWy4oA5gFZ+C7LBB52SSYXIa4r5sdf7LrwvxqN3X+ c9Xq0YuKxrZZzXrEdagf+BoBO+Vj3CcqWsMMePeQznvJsMZmj5PXsfxW7s9uL1pp5dCs +xLd3Zj+nTmFNqhFNaUqQA4AgF+G/Umu8HwyJ1qR1bMeq/d0HYD1K+WLiVIkQ9WpNTSw YhEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Ny1k40kzIrHHCzc4luLi6jxfoUiVi4oP/fRFHlC/+iQ=; b=WoEGfE69vz2+l7OWrrKI0Zux5Spolg2U9e+A3/9hE1p86iV4Lt4RLHQcg+s16mviXu 25KZA0Dy7YLJz6k4YOCzlG9F0c6te44xVoeJcelHTvULmojBErAMoMyPUEWQQfnvIXJA YHWQft9U/TnJJDp+zsUi3VnnNJeXrkEjI3IBL8HQ92D/WCRdv4+Sz/PB2NI/UbkcUFhr QwC7nwQilLTCulyhGEv1I9c0g2Mv0DvZ1rde6ZTSMJRAmae9QP6cmpGf1HP8DzZ+XdZk jIKkdZfYKJB7hNCZvWFa1fZvlkp6fUzbyxEjqNo87q8GrrJp/9U2jpbvE7DCNpMf+zmj kGeg== X-Gm-Message-State: AG10YOTVnMpK+OgCiq4lmlfsuASFH/x/pqqdayGQYN4N29qxXmGOmYnmR/vXd1USeU82Ig== X-Received: by 10.194.112.98 with SMTP id ip2mr48303498wjb.24.1456448597026; Thu, 25 Feb 2016 17:03:17 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id ei9sm10246824wjd.40.2016.02.25.17.03.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 17:03:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <6635cd58-2d42-46fe-85b4-287f1e0eb05d@default> 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:113823 Archived-At: On 02/24/2016 03:31 AM, Drew Adams wrote: > The fix to your code and theirs is trivial. 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. > Bit if you must, rename the current, bugged implementation of > `bounds-of-thing-at-point' to `bounds-of-thing-at-or-after-point'. A rename will break third-party code just as well. > 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'. Won't be usable in packages targeting older versions. I'm not saying it's entirely out of the question, but personally, I'm not convinced. > 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 (= the bug fix). Change > the Emacs code that uses the broken `bounds-of-thing-at-point' to > use `bounds-of-thing-at-point-strict'. We can add bounds-of-thing-at-point-strict even without changing the existing function. Patch welcome, I think. > 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. Maybe there aren't too many. Will you do the research on this? > 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. Any such client would be forced to call bounds-of-thing-at-point-strict twice. Which is not particularly ideal. >> 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. Thanks for that. > Look at `goto-char' or any other char-counting functions. If you > move point "to" character 2, point = 2. The char "at" point is the > char after point - point is before the char that has the same number > as point. When point = 2 the cursor position (aka point) is between > chars 1 and 2, and we say point is "at" (or "looking at") char 2. Yup. But when we say "word X ends at position P", P is after the last character of X, not before. > Before is not at (= after). Ends at ORIG does not mean ends before > ORIG. Think of the semantics of `match-end', or the last argument of `substring'. > 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. Even though the comment says that. > But I think you either try to see or you don't. I cannot make > you see. 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?