From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 14 18:38:54 2011 Received: (at submit) by debbugs.gnu.org; 14 Aug 2011 22:38:55 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QsjKY-0006Wk-6c for submit@debbugs.gnu.org; Sun, 14 Aug 2011 18:38:54 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QsjKW-0006We-GR for submit@debbugs.gnu.org; Sun, 14 Aug 2011 18:38:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QsjIu-00089w-V8 for submit@debbugs.gnu.org; Sun, 14 Aug 2011 18:37:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:44435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsjIu-00089r-Ta for submit@debbugs.gnu.org; Sun, 14 Aug 2011 18:37:12 -0400 Received: from eggs.gnu.org ([140.186.70.92]:55834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsjIt-0006a8-AU for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2011 18:37:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QsjIs-00089a-Db for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2011 18:37:11 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:30610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsjIs-000898-8R for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2011 18:37:10 -0400 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7EMb5XZ000864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 14 Aug 2011 22:37:07 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7EMb4Dc017964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Aug 2011 22:37:04 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7EMawEN026625 for ; Sun, 14 Aug 2011 17:36:58 -0500 Received: from dradamslap1 (/10.159.57.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 14 Aug 2011 15:36:58 -0700 From: "Drew Adams" To: Subject: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Date: Sun, 14 Aug 2011 15:36:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: Acxa0qnnTSxJRpcDRGqeGIE3JSLZfw== X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E484E13.0015,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) emacs -Q In a Lisp buffer, put point after a list: just after the closing paren. M-: (bounds-of-thing-at-point 'sexp) It should return nil, since there is no sexp at point. Instead it returns the bounds of the sexp at the previous char (the closing paren). The fix is to change these two sexps in the code: (<= orig real-end) SHOULD BE (< orig real-end) (<= orig end) SHOULD BE (< orig end) The tests for the THING'S beginning are correct - they should be <=, as they are. But the tests for the THING's end are incorrect - they should always be <. The reason is that 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. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2011-08-08 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.5) --no-opt' From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 28 21:44:52 2015 Received: (at 9300) by debbugs.gnu.org; 29 Jul 2015 01:44:52 +0000 Received: from localhost ([127.0.0.1]:33100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZKGQN-0001hK-UX for submit@debbugs.gnu.org; Tue, 28 Jul 2015 21:44:52 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:30807) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZKGQK-0001h7-QE for 9300@debbugs.gnu.org; Tue, 28 Jul 2015 21:44:49 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t6T1ik0h030091 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <9300@debbugs.gnu.org>; Wed, 29 Jul 2015 01:44:47 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t6T1ikUq018621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <9300@debbugs.gnu.org>; Wed, 29 Jul 2015 01:44:46 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t6T1ik0J017660 for <9300@debbugs.gnu.org>; Wed, 29 Jul 2015 01:44:46 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 28 Jul 2015 18:44:44 -0700 (PDT) From: Drew Adams To: 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: <> In-Reply-To: <> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.7 (---) ping. I rediscovered by accident that this bug still exists, because I had assumed it would be fixed in Emacs 24, and my code was mistakenly but in-vain-hopefully treating it as (assumed) fixed in 24. Since I use my library that doesn't have the bug I did not run across it myself anymore. ;; The correct code here is (setq beg thg-end). However, unless you ;; use my library `thingatpt+.el' or unless Emacs bug #9300 is fixed ;; (hopefully in Emacs 24), that will loop forever. In that case we ;; move forward a char to prevent looping, but that means that the ;; position just after a THING is considered to be covered by the ;; THING (which is incorrect). ;; (setq beg (if (or (featurep 'thingatpt+) (> emacs-major-version 23)) thg-end (1+ thg-end))) From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 15 08:33:25 2016 Received: (at 9300) by debbugs.gnu.org; 15 Jan 2016 13:33:25 +0000 Received: from localhost ([127.0.0.1]:49727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aK4VJ-0006dm-9T for submit@debbugs.gnu.org; Fri, 15 Jan 2016 08:33:25 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:30828) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aK4VH-0006dV-7V for 9300@debbugs.gnu.org; Fri, 15 Jan 2016 08:33:23 -0500 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 u0FDXGu7005924 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <9300@debbugs.gnu.org>; Fri, 15 Jan 2016 13:33:17 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0FDXGYV021332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <9300@debbugs.gnu.org>; Fri, 15 Jan 2016 13:33:16 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0FDXG9g027403 for <9300@debbugs.gnu.org>; Fri, 15 Jan 2016 13:33:16 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 15 Jan 2016 05:33:15 -0800 (PST) From: Drew Adams To: 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: <> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > Sent: Tuesday, July 28, 2015 6:45 PM >=20 > ping. >=20 > I rediscovered by accident that this bug still exists, because > I had assumed it would be fixed in Emacs 24, and my code was > mistakenly but in-vain-hopefully treating it as (assumed) fixed > in 24. Since I use my library that doesn't have the bug I did > not run across it myself anymore. >=20 > ;; The correct code here is (setq beg thg-end). However, unless you > ;; use my library `thingatpt+.el' or unless Emacs bug #9300 is fixed > ;; (hopefully in Emacs 24), that will loop forever. In that case we > ;; move forward a char to prevent looping, but that means that the > ;; position just after a THING is considered to be covered by the > ;; THING (which is incorrect). > ;; > (setq beg (if (or (featurep 'thingatpt+) (> emacs-major-version 23)) > thg-end > (1+ thg-end))) A user of thingatpt+.el (which has the fix) sent me this today: > I miss in bug #9300 someone giving a comment about why the vanilla > bounds-of-thing-at-point should behave like that. Maybe a second > ping? ping. It's a trivial fix to perform. I hope you will apply it. Thx. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 20:01:21 2016 Received: (at 9300) by debbugs.gnu.org; 23 Feb 2016 01:01:21 +0000 Received: from localhost ([127.0.0.1]:38687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aY1Lt-0007Gx-Jy for submit@debbugs.gnu.org; Mon, 22 Feb 2016 20:01:21 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:37460) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aY1Ls-0007Gk-7n for 9300@debbugs.gnu.org; Mon, 22 Feb 2016 20:01:20 -0500 Received: by mail-wm0-f49.google.com with SMTP id g62so188420939wme.0 for <9300@debbugs.gnu.org>; Mon, 22 Feb 2016 17:01:20 -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-transfer-encoding; bh=tFtMc0d+O2dtv9aYx3tCgRQX3gBH7lCavNpsVLgRsNs=; b=zpgFg0VC7tdJfY+DjAA4Vfx344XtFTjPXL8oTqWCJFVNewWAwEdzuDry+SdRNrggGw J2NIZweqbdc2Rz+8pQL4qLeoOqDYXM1vopbvZ+bDE6zlMyhHTuY93R/zHjTnelVXt1b+ k3QWUvwOodnB3bfAxN1RHi2czDjdZI8knQLiWDjU0NL5l6FVCtXz+bFr97R0FaGXI8Nt QjHIQIDXIFI9Eg/EKQVMOHuIXcXkTUmX1ictWKBdBxhFr75eV69ugwnyg18x713biNw9 l17mM0BT8BQaHOKLhwcNihAlU8+U7jfWsZi0ytww3tww+0DLBIHq1G49ghi3aJ/yfVoO KPtg== 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-transfer-encoding; bh=tFtMc0d+O2dtv9aYx3tCgRQX3gBH7lCavNpsVLgRsNs=; b=J8jRhJ81LnDvpVqYZaEaWPRQE0qhPZe1TnK4o0K2zESpY1toDRcBFZjdliPWne4pLu CO/YxIXf5Uz8zJIvwHaziwfELfADZ/rpynUYFH88uhtNf/rmNE8wpLUo1qhOVRR/tdk6 BkJii1tioBSrO9Th8T/6qSZpaTIK28UmiXDbQsH+wvx33hyYo2biSGHdMfhWhKIpmrrM g2vRRcY7Yj5PUWsapkfmMIbfI3wA5kTEbSu651R3yaVr8kFS+6gpB05NkPWiiRXF4Nzj NJ3khHc0PXU+y3lz8ecGBcUoVDFEXhz5Ozg9xis6fpb4/pCkRCi5L85jX7C5pKPRC0h5 A0jw== X-Gm-Message-State: AG10YOQmopsrrfzQ2oa+0P1lFhUV8v2F3tlbSVQk7Dw7rY0+Rqkc3Nd8ZwkKC8WP6sd53A== X-Received: by 10.28.131.141 with SMTP id f135mr14915787wmd.33.1456189274600; Mon, 22 Feb 2016 17:01:14 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id n131sm23426363wmf.9.2016.02.22.17.01.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 17:01:13 -0800 (PST) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Drew Adams , 9300@debbugs.gnu.org References: < From: Dmitry Gutov Message-ID: <56CBAF58.2000708@yandex.ru> Date: Tue, 23 Feb 2016 03:01:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) I'm not sure it should be fixed. Your reasoning seems valid, however by now this behavior is ingrained into my expectations of how thing-at-point should behave. This would be a breaking change. For instance, it will make (bounds-of-thing-at-point 'symbol) unsuitable for use in a completion-at-point-functions element, to compute the first two values of the returned list, because during completion you're most often "after" the symbol. And I do use it for that purpose in one third-party package. emacs-eclim also uses it in eclim-java-show-documentation-for-current-element. At the very least, this will change the existing behavior. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 01:38:11 2016 Received: (at 9300) by debbugs.gnu.org; 23 Feb 2016 06:38:11 +0000 Received: from localhost ([127.0.0.1]:38892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aY6bq-0001o2-RE for submit@debbugs.gnu.org; Tue, 23 Feb 2016 01:38:11 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:51288) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aY6bp-0001np-3w for 9300@debbugs.gnu.org; Tue, 23 Feb 2016 01:38:09 -0500 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 u1N6c1Oj030519 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Feb 2016 06:38:02 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1N6c031013392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 06:38:01 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1N6bwbq012610; Tue, 23 Feb 2016 06:37:58 GMT MIME-Version: 1.0 Message-ID: <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> Date: Mon, 22 Feb 2016 22:37:57 -0800 (PST) From: Drew Adams To: Dmitry Gutov , 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <56CBAF58.2000708@yandex.ru> In-Reply-To: <56CBAF58.2000708@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > I'm not sure it should be fixed. Your reasoning seems valid, > however by now this behavior is ingrained into my expectations > of how thing-at-point should behave. >=20 > This would be a breaking change. For instance, it will make > (bounds-of-thing-at-point 'symbol) unsuitable for use in a > completion-at-point-functions element,=20 Why do you think so? Have you tried it? It does not affect the behavior for THING =3D `symbol' at all. > to compute the first two values of the returned list, because > during completion you're most often "after" the symbol. So? Not a problem. Put point after a symbol - you get the same answer as now. > And I do use it for that purpose in one third-party package. >=20 > emacs-eclim also uses it in > eclim-java-show-documentation-for-current-element. At the > very least, this will change the existing behavior. This is the design of the thingatpt code, and the reason why `<=3D' instead of `<' is a bug:=20 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 02:59:12 2016 Received: (at submit) by debbugs.gnu.org; 23 Feb 2016 07:59:12 +0000 Received: from localhost ([127.0.0.1]:38932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aY7sG-0005Ph-Lq for submit@debbugs.gnu.org; Tue, 23 Feb 2016 02:59:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39861) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aY7sF-0005PU-3N for submit@debbugs.gnu.org; Tue, 23 Feb 2016 02:59:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aY7s9-00049s-1E for submit@debbugs.gnu.org; Tue, 23 Feb 2016 02:59:05 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY7s8-00049o-UT for submit@debbugs.gnu.org; Tue, 23 Feb 2016 02:59:04 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY7s7-0002Hk-RZ for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 02:59:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aY7s2-00047g-Oj for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 02:59:03 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:64534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY7s2-00047X-F8 for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 02:58:58 -0500 Received: from [192.168.178.35] ([77.12.96.117]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0LsL60-1ZoB8C2yXA-01248U for ; Tue, 23 Feb 2016 08:58:56 +0100 Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: bug-gnu-emacs@gnu.org References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: <56CC1175.3080101@easy-emacs.de> Date: Tue, 23 Feb 2016 08:59:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EnJ5mHliG9Cth8Nm9t4QY6Ua1h1x9QoWq7TY+NZvlYbu16MgHYD gl4PoDUqLju5IKXJzpJf6ux9H/0KaidIdbHUHjC+aQLaZRAosZrREptU34xrX2XN/89A0wP LWAUI/7x5YdkDzYsGNVT+9pux1Yia9yd20JeJ95NXxeipMupz56WiAvlSb0R2GkRCraakuE pjv+W5gb7ERLN39yR8Q4Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:KOSfFsxrLW0=:W8WWavuPUmtZcxjAUrpQ9m uwoEp4+p38An1V5cBz7rhVcaV7fGika4CTbvFQGDDJDchI4bC2s4NAIuWLAAMSuNo9WQFR8zG 5MEGCGxUSrf/8ECIfL5uNfosY0w99iG+ToFnETFDIKuUC1YFeRc0idDZDHgvanamVFxIefxH2 0g5tUZelOsxME7kWLcGAHUCdZefbnv1ifOu9WCSHP3jxhSpTVcsULYMh/umxkelELGCfNFZcs H/OUhwqs8rbHNoKn+3WF+4YHDiXpiJIoPV0NipILbwKU/Tz9rzPqURxXH6MjiOmW1JeLFmcSQ msRvgIXtBJ48ejCl7Prp/sy+nWAl7vbMUmVpTOEB904d8Edh00mk2wbCTO/+m1k70jnI1a2gB 3DATFxj7cU32C6eSNHQnul6N23KEPdw1kir03wuGoeP+X7k1cLFlzkxf3D+rfOzinZpiHCFFV DVidycu+S6Q14AAtWOm4o99/51bkm6FiubTKN/qm6c4GilnGHqwa62EN4ZxRLMrVGB300UE4s 45ZBX5Cp5MBKrEhpFWW21ocDzIxb3ICMpxVB6bDYDTe7QJfcGBrPKp3bpyNKrmvC77iuzi6uG hyFpKq0pDhLDkcy8s0Q/8OfxGQiS5f2m/udRjglQwibmgfgWCdKy9IZt2b4ACvdxTb2cyCbV1 Om3WiuPLs2kvQFdZ+1vElGcSe+yO4eELfGuPwo43l2t/tCZ0Q5M6z5JYWgoW0itY+JoqNFcyk SYrdGeEi0RbSxzI8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 23.02.2016 07:37, Drew Adams wrote: >> I'm not sure it should be fixed. Your reasoning seems valid, >> however by now this behavior is ingrained into my expectations >> of how thing-at-point should behave. >> >> This would be a breaking change. For instance, it will make >> (bounds-of-thing-at-point 'symbol) unsuitable for use in a >> completion-at-point-functions element, > Why do you think so? Have you tried it? It does not affect > the behavior for THING = `symbol' at all. > >> to compute the first two values of the returned list, because >> during completion you're most often "after" the symbol. > So? Not a problem. Put point after a symbol - you get the > same answer as now. > >> And I do use it for that purpose in one third-party package. >> >> emacs-eclim also uses it in >> eclim-java-show-documentation-for-current-element. At the >> very least, this will change the existing behavior. > This is the design of the thingatpt code, and the reason why > `<=' 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 what I changed at https://github.com/andreas-roehler/thing-at-point-utils ar-forward-list-atpt would stop at closing paren, not one char after as forward-sexp would do. Char after FORM in not considered inside in sense of at-point. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 05:22:14 2016 Received: (at 9300) by debbugs.gnu.org; 23 Feb 2016 10:22:14 +0000 Received: from localhost ([127.0.0.1]:39225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYA6g-0003ht-Bw for submit@debbugs.gnu.org; Tue, 23 Feb 2016 05:22:14 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:37762) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYA6f-0003he-1b for 9300@debbugs.gnu.org; Tue, 23 Feb 2016 05:22:13 -0500 Received: by mail-wm0-f50.google.com with SMTP id g62so202856034wme.0 for <9300@debbugs.gnu.org>; Tue, 23 Feb 2016 02:22:13 -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=oa7ZVHIvgJq+qBlqV6EtpnvEYIT8AgitP8QKHz65VQ8=; b=Zd60Cn2FNpVmAPRT2gNqMmP5nhQpa464BMFevXSScCxl4CnVcJ8eYbWbVvK63hKGkF 8d36WhTKyuu54SXbpBYoJv5FP5HTiIqYDa1KU3/4K3HmX3YoZMGUbFnfWS+w3jVb5hqS ERNnNRT40h2blf+vihl2iqX+Z7EOWKyR0/VfkX/57lkkO96dTRKuef6glAPR4EylLVQv J4xmwibxM9RDbOqS9nUhCFRg1tmZ4Zn+qdP6vPHNdQTZllmvR/tTM8F1mnQ9kEQt7fBQ 80Ovpkcf4GRHMOaAUOMpM6iVRgbl6yj6yocjrQOyXhIaNFzysSqJE/lIP3WCX4wYhFS6 9ZBA== 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=oa7ZVHIvgJq+qBlqV6EtpnvEYIT8AgitP8QKHz65VQ8=; b=L6ro7cg23/AU9DBp1jHGgK4uWLb4Z/eQTijl+QGXcVEdWQxhX24mn51rdpFoTobfbW GZgbZWlsVry8By/d8+zvsPV4bFSZ5Mfbxm4g7sQXmKlY7jwpaP/V8hJLjzWIrUnwc5ue /HCLVyx7dco2ETEcFIufI5NZf43gr7DTx2QcRrkHJKkwsMjlmj/j5yi34ot074SDQxLH A7jcyg4VxIMOB1TJ1dENANzl1tHRlfZ6im1Gpjl+Yce4W2GDr7x2aSq1nEcEW0Nt0i+z W4bv95nwkSQFAuLTdXxpehE4EQhB1fFlZVGh1DfRT46rj7LDMX2UsHTwb1EYtcb8fTHQ 7WcQ== X-Gm-Message-State: AG10YORhO4HlaV5qXpvVIL5erLxKpPQbBrvLU1xuBz+/aS78wvlsYQtL0eriXqSNAEsmsw== X-Received: by 10.28.64.198 with SMTP id n189mr16591424wma.85.1456222927553; Tue, 23 Feb 2016 02:22:07 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id a128sm25385789wmh.6.2016.02.23.02.22.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 02:22:06 -0800 (PST) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Drew Adams , 9300@debbugs.gnu.org References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> From: Dmitry Gutov Message-ID: <56CC32CD.5050906@yandex.ru> Date: Tue, 23 Feb 2016 12:22:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/23/2016 08:37 AM, Drew Adams wrote: >> This would be a breaking change. For instance, it will make >> (bounds-of-thing-at-point 'symbol) unsuitable for use in a >> completion-at-point-functions element, > > Why do you think so? Have you tried it? It does not affect > the behavior for THING = `symbol' at all. Tried it, and yes it does. Otherwise, I wouldn't understand what this bug is about. >> to compute the first two values of the returned list, because >> during completion you're most often "after" the symbol. > > So? Not a problem. Put point after a symbol - you get the > same answer as now. You're contradicting the very title of this bug report. > This is the design of the thingatpt code, and the reason why > `<=' 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 11:15:34 2016 Received: (at 9300) by debbugs.gnu.org; 23 Feb 2016 16:15:34 +0000 Received: from localhost ([127.0.0.1]:41528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYFcc-0002vk-3D for submit@debbugs.gnu.org; Tue, 23 Feb 2016 11:15:34 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:24095) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYFcZ-0002vU-PK for 9300@debbugs.gnu.org; Tue, 23 Feb 2016 11:15:32 -0500 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 u1NGFPqN025495 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Feb 2016 16:15:25 GMT 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 u1NGFP0s009684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 16:15:25 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1NGFODx018968; Tue, 23 Feb 2016 16:15:24 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 23 Feb 2016 08:15:23 -0800 (PST) From: Drew Adams To: Dmitry Gutov , 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> <56CC32CD.5050906@yandex.ru> In-Reply-To: <56CC32CD.5050906@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > Tried it, and yes it does. Otherwise, I wouldn't understand what > this bug is about. Sorry, my bad (it's been several years since I filed this). Yes, it should return nil, as there is NO symbol at point. > Your reasoning seems valid, however by now this behavior is > ingrained into my expectations of how thing-at-point should behave. 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. 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? The purpose of thingatpt.el is not only to maximize finding a THING that is _near_ point. One purpose is to test whether there IS a THING AT point. If your code wants _only_ to complete a name (or other THING) that is at or _near_ point, then it should temporarily move to where it really wants to pick up the name (or other THING). Your code should not depend on an off-by-one bug, however longstanding. I am well aware of how useful picking up a name at or _near_ point can be, either to complete it or to use it as a default value. I see (in emacs-devel) that you are now looking into picking up a name near point - but you are limiting that to the same line. I'm glad someone is finally getting around to this. FWIW, I did it in 1996 and have been using it ever since (I proposed it for Emacs). But my code does not limit looking to the current line. Users can control what "near" means using these variables, which are the max number of chars and lines to search from point, left-and-right and up-and-down, respectively: (tap-)near-point-x-distance - default 50 chars (tap-)near-point-y-distance - default 50 lines These variables are used typically by functions that invoke `tap-thing/form-nearest-point-with-bounds', and that provide default text for minibuffer input or text to complete. `thingatpt+.el' includes these "nearest-point" functions (with library prefix `tap-'): bounds-of-form-nearest-point bounds-of-list-nearest-point bounds-of-sexp-nearest-point bounds-of-symbol-nearest-point bounds-of-thing-nearest-point color-nearest-point color-nearest-point-with-bounds find-fn-or-var-nearest-point (a command) form-nearest-point form-nearest-point-with-bounds list-contents-nearest-point list-nearest-point list-nearest-point-with-bounds list-nearest-point-as-string non-nil-symbol-name-nearest-point non-nil-symbol-nearest-point number-nearest-point region-or-word-nearest-point region-or-non-nil-symbol-name-nearest-point sentence-nearest-point sexp-nearest-point sexp-nearest-point-with-bounds string-contents-nearest-point string-nearest-point symbol-name-nearest-point symbol-nearest-point symbol-nearest-point-with-bounds thing-nearest-point thing-nearest-point-with-bounds unquoted-list-nearest-point unquoted-list-nearest-point-as-string word-nearest-point So I do have some experience with the kinds of uses of thing-at-point that you are interested in. But there are lots of other uses, as well, which rely on its behavior being usable in repetitive (iterative, recursive) contexts. And that means relying on its treating the position after a thing differently from the position before the thing, wrt whether or not there is a THING at that position. If you never make use of thing-at-point, beyond wanting to pick up a thing at or near point, and you don't care much about exactly where point is in relation to the thing, then you won't understand the importance of this bug. My code that does use thing-at-point repetitively needs the basic code to distinguish whether there is a thing at point in a precise way. It is not enough to just maximize the possibility of obtaining a thing near point. The point of such code is instead to perform operations on occurrences of a specific THING over a given region of text. One example is `isearchp-thing', which does incremental search within THING search contexts. The contexts are determined by scanning a region/buffer progressively, and this depends on basic thing-at-point functions doing the right thing wrt whether there is a THING at a given point. The scanning function is `isearchp-thing-scan', and it is in its code that you will find the comment included in this bug report: ;; The correct code here is (setq beg thg-end). However, ;; unless you use my library `thingatpt+.el' or unless Emacs ;; bug #9300 is fixed that will loop forever. In that case ;; we move forward a char to prevent looping, but that means ;; that the position just after a THING is considered to be ;; covered by the THING (which is incorrect). (setq beg (if (featurep 'thingatpt+) thg-end (1+ thg-end))) > This would be a breaking change. For instance, it will make > (bounds-of-thing-at-point 'symbol) unsuitable for use in a > completion-at-point-functions element, to compute the first > two values of the returned list, because during completion=20 > you're most often "after" the symbol. And I do use it for > that purpose in one third-party package. See previous. It is the calling code that is wrong, here (and no need for quoting "after" - you are after, not on, the symbol). The calling code should instead check `bounds-of-thing-at-point' at the right position. There has to be a difference between there being a THING at point and there not being a THING at point. And thingatpt.el is designed for there not being at THING at point when, well, there is no THING at point. At point is not the same as before point. (Yes, point is _between_ characters. But one or the other, but not both, positions wrt a char that is part of THING needs to be picked as its start or end. Especially for uses of thing-at-point that are iterative or recursive, it is important that either the position after the last char or the position before the first char not be included in the THING "at" that position. This should be obvious, but is not paid attention to if one's only interest is in grabbing some text that is _near_ point but might not be exactly _at_ point. > At the very least, this will change the existing behavior. Yes - it is a bug fix. The current behavior is bugged. > > 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. >=20 > That's not a quote from thingatpt.el. It is nevertheless the design (intention), clear from the code. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 19:52:47 2016 Received: (at 9300) by debbugs.gnu.org; 24 Feb 2016 00:52:47 +0000 Received: from localhost ([127.0.0.1]:41827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYNh9-0000r3-Kt for submit@debbugs.gnu.org; Tue, 23 Feb 2016 19:52:47 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38588) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYNh7-0000qn-Ic for 9300@debbugs.gnu.org; Tue, 23 Feb 2016 19:52:45 -0500 Received: by mail-wm0-f54.google.com with SMTP id a4so8057206wme.1 for <9300@debbugs.gnu.org>; Tue, 23 Feb 2016 16:52:45 -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=i5igieL3e4R5q3Nbtjm9vzW4zFpbkJa2ZHFOMLHSmcU=; b=UyMyeCXg+EdycJTATuoGtCiGAEtSBXtpUAJqlSWPFgZYLC/jGngFcOzCFdkUFNge5d zzpaz2B1tSDW5mgQiMTM4osmh/Z0npzguep8kpMKlBh8oIbJ9oe0fTQL7JqEMt3J54Rq faCRkNaOlyELz9j0JN+ATGsQvUpH1ls8zb4GvHuKv0JJjeYrS3pmrrz7MGarEgSTIKY8 yyPMwAcPj55yUfPaPqOlRhIQOL1W76ZZ03XEweY+J4UKpUanjdMY8QbPTUyy8dAXZSpE tMHZxOcNU4XxSWj3egR6Jh5OYNXCwr9CPHkAoC0UAAp+czqwZDL7L0Zjhu7wY7RQVW37 xA2w== 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=i5igieL3e4R5q3Nbtjm9vzW4zFpbkJa2ZHFOMLHSmcU=; b=Ol6wBxMrznKNKAnQxeUeRkR/9klu3CmPaAJyZuA/DcrAjT6Uqpzf1NPQukC01+251f YWBpSb4HMTB0u/xQsO6iqg+ZjMz1woYad3JW2Q9yAsUcWT1aUgtM1nznuBcwiIq0kcft oRM+Kpr2+49RDLa6v6HxHffB1/x+NSlhL80MSf2WrjoWywN1ss96Sp/+Fz7cHRO4USM4 9mbpbKpGF4UPf/9iqdX2r8IDxPFh+q6AEVL7EEqTkH8XcQUXouYdhyRhfLl8YUWVTwUn asRFfM7YMqyqy2MxmNCXvZnyCWMLJqVnA5AsSNmsnQjMIECYCtv/bslWDUoYpDBJt2Mq yxAA== X-Gm-Message-State: AG10YOT+uzRJ/bDCj314RhnQNE2dXMLdOGu+s/d3+FucIgciKOOSVHayRTAtL5l1r2CMLw== X-Received: by 10.194.184.234 with SMTP id ex10mr34555122wjc.8.1456275159972; Tue, 23 Feb 2016 16:52:39 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id r10sm360763wjz.24.2016.02.23.16.52.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 16:52:38 -0800 (PST) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Drew Adams , 9300@debbugs.gnu.org References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> <56CC32CD.5050906@yandex.ru> From: Dmitry Gutov Message-ID: <27990eb0-3d4e-62c7-257d-7ea7a8204e2d@yandex.ru> Date: Wed, 24 Feb 2016 02:52:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/23/2016 06:15 PM, Drew Adams wrote: > Yes, it should return nil, as there is NO symbol at point. 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. > 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. What I'm saying is, "fixing" it will most likely break code in the wild. Not just mine. > 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? They can call (bounds-of-thing-at-point 'foo), and then compare the cdr with the value of point. > The purpose of > thingatpt.el is not only to maximize finding a THING that is > _near_ point. One purpose is to test whether there IS a THING > AT point. We're a long way from maximizing it. To see something closer to the other end of the spectrum, see the definition of find-tag-default-bounds before http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=e72a26e00981a508569a0856125061310a3f64ac. > I see (in emacs-devel) that you are now looking into > picking up a name near point - but you are limiting that to the > same line. Not at all, see above. >>> This is the design of the thingatpt code, and the reason why >>> `<=' 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. I'm not so clear on that. The following comment tells me the opposite (the position where a substring ends is normally the one _after_ its last character): ;; Try a second time, moving backward first and then forward, ;; so that we can find a thing that ends at ORIG. If we didn't need to be able to find a thing that ends just before point, 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 20:31:15 2016 Received: (at 9300) by debbugs.gnu.org; 24 Feb 2016 01:31:15 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: <6635cd58-2d42-46fe-85b4-287f1e0eb05d@default> Date: Tue, 23 Feb 2016 17:31:02 -0800 (PST) From: Drew Adams To: Dmitry Gutov , 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> <56CC32CD.5050906@yandex.ru> <27990eb0-3d4e-62c7-257d-7ea7a8204e2d@yandex.ru> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 20:03:24 2016 Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 01:03:24 +0000 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 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 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) 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) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Drew Adams , 9300@debbugs.gnu.org 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> From: Dmitry Gutov Message-ID: Date: Fri, 26 Feb 2016 03:03:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <6635cd58-2d42-46fe-85b4-287f1e0eb05d@default> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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? From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 20:44:17 2016 Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 01:44:18 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: <05f0b24b-1a52-4fa4-9f22-f34f5ed33556@default> Date: Thu, 25 Feb 2016 17:44:07 -0800 (PST) From: Drew Adams To: Dmitry Gutov , 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING 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> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 05:15:54 2016 Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 10:15:54 +0000 Received: from localhost ([127.0.0.1]:46932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZFRB-0003tY-SJ for submit@debbugs.gnu.org; Fri, 26 Feb 2016 05:15:54 -0500 Received: from mail-wm0-f43.google.com ([74.125.82.43]:35037) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZFRB-0003tL-0r for 9300@debbugs.gnu.org; Fri, 26 Feb 2016 05:15:53 -0500 Received: by mail-wm0-f43.google.com with SMTP id c200so65628994wme.0 for <9300@debbugs.gnu.org>; Fri, 26 Feb 2016 02:15:52 -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-transfer-encoding; bh=H3dNtUeHm+4mDvgZAgrVpEerzXBME6p4qdwzsyvuufY=; b=kEMJNSL6ppXth0qvlkZPmXFhX+OfPexJTB6F6e5P8vDqXuJ/FPAszO5xq2QCM6mTkk MAlApXddAFipeqzj9UB61QDcKvqXtlrOEvrPmtzSyx3CAXCJYTjVKpXHYHWQRMJHMuBe IrXvS0TtIrCgTARTgLCViOX15PMWD47ovq36v2Wln47VbTsDC4KxiGDWwKdcZSZTgsoX /+SshbOyd7aj9Yl+ShB8kL3ikbGiT1hWKUu9O2A3wUJzvhC34sq88fTN8W58m0faB2o4 ZElhKe0gtIcItDIrMGq7nYjI3OStHYduzSqUaXMyv+hoGaSgjpBdkJ0ObJDkTVJq66lP Ollg== 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-transfer-encoding; bh=H3dNtUeHm+4mDvgZAgrVpEerzXBME6p4qdwzsyvuufY=; b=HR0rAru+L4upeIgzps0paLbV/NUa2p5wBnXNLBAR5IHGGmkOitXeIQX+yhB6EHOjjL EtXQ+vdTZx9Dz874ptWdFR4bAAI53mFN5gB+JylNwN34Ifo6rk67w+uSpiCaS1raDIV6 b2fZulEmf1eDo/r5nkCY5r6dneY0YbY+nMZjbFu466S0J2FQtnxGY00sPjYJrue5czZZ 8xkNgDGjSRJxdkjbMimgvk7bRgXRwUl9N7nsTrFusZuo1hoCqkrXH+231eYWi4ac4tTB LJnkn0CopGexZBxde1dsex2plFMwaQA20eYZjyld0WGBrOeBJOHfDgUXL00CQOp+s3Zu RJCw== X-Gm-Message-State: AD7BkJKjxmMnDQ0uGWKkJmIrexUVgTFQonuaPXpsDVeKJh33XZp1BUS85lgEkeHBHLy3/g== X-Received: by 10.28.227.134 with SMTP id a128mr2413326wmh.67.1456481747518; Fri, 26 Feb 2016 02:15:47 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id z127sm2207539wme.5.2016.02.26.02.15.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 02:15:46 -0800 (PST) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Drew Adams , 9300@debbugs.gnu.org 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> From: Dmitry Gutov Message-ID: <503db28a-d430-8a5d-a26d-e95890da58b9@yandex.ru> Date: Fri, 26 Feb 2016 12:15:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <05f0b24b-1a52-4fa4-9f22-f34f5ed33556@default> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On 02/26/2016 03:44 AM, Drew Adams wrote: > 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. If the thing _begins_ at point, and the third-party code in question calls (save-excursion (forward-char -1) (thing-at-point 'foo)), they will get nil. >> Maybe there aren't too many. Will you do the research on this? > > Does anyone need to? I imagine so. > 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 never mentioned anything Eclipse-related in this bug. >>> 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. > > Not at all. Why do you say that? See above. >> 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. If the list is at the end of the buffer, it gives me an empty string, or a string of spaces. So yeah, this particular "thing" seems bugged. > 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. Because there is no such example. > 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. Not just mine. I believe I have demonstrated that the code has been written with exactly this expectation in mind. And stayed like that for decades. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 09:39:44 2016 Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 14:39:44 +0000 Received: from localhost ([127.0.0.1]:47066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZJYV-0005Do-Tp for submit@debbugs.gnu.org; Fri, 26 Feb 2016 09:39:44 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:47878) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZJYU-0005Db-1l for 9300@debbugs.gnu.org; Fri, 26 Feb 2016 09:39:42 -0500 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1QEdZLs003259 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Feb 2016 14:39:36 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1QEdYLH029429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 14:39:35 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1QEdY9c029588; Fri, 26 Feb 2016 14:39:34 GMT MIME-Version: 1.0 Message-ID: <76b6983a-da47-48da-ba9b-20ede56ed691@default> Date: Fri, 26 Feb 2016 06:39:32 -0800 (PST) From: Drew Adams To: Dmitry Gutov , 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING 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> In-Reply-To: <503db28a-d430-8a5d-a26d-e95890da58b9@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > 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. >=20 > If the thing _begins_ at point, and the third-party code in question > calls (save-excursion (forward-char -1) (thing-at-point 'foo)), they > will get nil. So what? The point is that if code wants to get a thing at point OR a thing at point-minus-one, then that's exactly what it should check - which is, BTW, what the currently bugged code does. > > 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. >=20 > I never mentioned anything Eclipse-related in this bug. Sorry - "eclim". > >>> 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. > > > > Not at all. Why do you say that? >=20 > See above. No. Just use the current (bugged) implementation. It is a `bounds-of-thing-at-point-or-at-point-minus-one'. You might even provide a function that takes an other (e.g. optional) arg that is the other end of a range of positions over which to check whether there is a thing. Currently, you want the behavior of getting a thing at point or a thing that is point-minus-one. Add an argument to the new function that lets it return a thing that is at any of the positions between point and the new arg (a position). I only need to test for (and get) the thing at point (really at point). But other use cases might want what you want. > >> 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. >=20 > If the list is at the end of the buffer, it gives me an empty > string, or a string of spaces. So yeah, this particular "thing" > seems bugged. 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. The crucial point is that THINGs that end *before* point are not *at* point. That's all. And this applies to all kinds of THINGs. Whether or not there are bugs for particular kinds of THINGs is something else, and those should be fixed individually. Comments come to mind, IIRC. I have several such fixes in my code. But the basic off-by-one bug (this bug) needs to be fixed, if we expect coherent thing-at-point behavior and flexible, repeatable use. > > 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. >=20 > Because there is no such example. Sigh. > > 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. >=20 > Not just mine. I believe I have demonstrated that the code has been > written with exactly this expectation in mind. And stayed like that > for decades. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 10:25:39 2016 Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 15:25:39 +0000 Received: from localhost ([127.0.0.1]:47798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZKGx-0006Y2-5d for submit@debbugs.gnu.org; Fri, 26 Feb 2016 10:25:39 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:33774) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZKGv-0006Xp-Uf for 9300@debbugs.gnu.org; Fri, 26 Feb 2016 10:25:38 -0500 Received: by mail-wm0-f49.google.com with SMTP id g62so76882200wme.0 for <9300@debbugs.gnu.org>; Fri, 26 Feb 2016 07:25:37 -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-transfer-encoding; bh=BN8huYMNTLxtGw1kialrqlj9KZ0ZVeEkKGXOny2OYZ4=; b=Y262u1omMGpXmUG4EKHtcZsn9RC6rzlEa/XFnHaRUHp8czdo+LDzrC6erYLzYRUajh WZMJcONU9v2OeD73uYW46ihb0hiXce947cJZNmpGWMax+8uyKP+zithzzw5ZqPjCTmBN gENxPL4BCSHgRGlOmrk8KihBiWvjkH9Iqi58crHuw09v3egHcTegLK0i9yQbPgGBtth9 c9KpyfR50ITv/C1AVd/SFEBAAGaUM/nNm+Bnn3teB/q2aYQh6ox1DY8z9WIC0SK3TiuR bFBMGp4Lnd0ye9NQyeKXChGTtuZDFB50fj/7JzjkbrpVJWr9iupsDEO/RACMEFzPjADS Us9A== 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-transfer-encoding; bh=BN8huYMNTLxtGw1kialrqlj9KZ0ZVeEkKGXOny2OYZ4=; b=k0W0PAtTJUIahzP2c/VXqKeKlxo0Wf9tNEHCYnwz86/0RveldXgi0LpS0M2qCdM3DD piPGm6llLFahd+aBDxrxkV8/YzCmoVpQBWxH0pgdvhGUY3Wg5LOU+hxe9GJNPYr0etI6 OVQK20JZ7jtCiNVaXZzlB8PcYbUtP2Jc46kxoDX1vN4+10Us0j++C/npToPfTahl2i1N Bkw+W38Qonr+ML5ye+WhEvEDNg0sbvYbXZXTt+SQl1WyHa7uJSMVwD0w6Im0VKsftxkw isqCxnhVyLcsR9PxmpjiQxnfzk1lA42+VmenwMCNmWcx3SXXWpHlD1KmBYWiqhossCRI kfjw== X-Gm-Message-State: AD7BkJImokjy/DmlXg4yv/OMV6aF1b4WW2BKbRRyHC8xzm5Po6lvKYma11GNdWynqlaJ2Q== X-Received: by 10.28.173.71 with SMTP id w68mr3993839wme.88.1456500332315; Fri, 26 Feb 2016 07:25:32 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id et11sm12852755wjc.30.2016.02.26.07.25.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 07:25:30 -0800 (PST) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Drew Adams , 9300@debbugs.gnu.org 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> From: Dmitry Gutov Message-ID: <74937597-35e0-4ee9-10dd-cc33eedfb084@yandex.ru> Date: Fri, 26 Feb 2016 17:25:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <76b6983a-da47-48da-ba9b-20ede56ed691@default> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/26/2016 04:39 PM, Drew Adams wrote: >> I never mentioned anything Eclipse-related in this bug. > > Sorry - "eclim". My bad, it is indeed Eclipse-related. As for the rest, my first comment here still seems to be an appropriate response. Maybe someone else would like to comment as well? > 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. I'd be interested in a patch. Especially if it's orthogonal (as it should be) to whatever we decide in this bug. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 12:00:49 2016 Received: (at 9300) by debbugs.gnu.org; 26 Feb 2016 17:00:49 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: Date: Fri, 26 Feb 2016 09:00:27 -0800 (PST) From: Drew Adams To: Dmitry Gutov , 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING 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> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 05:21:21 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 09:21:21 +0000 Received: from localhost ([127.0.0.1]:47079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEvOT-0005gf-92 for submit@debbugs.gnu.org; Mon, 20 Jun 2016 05:21:21 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:35840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEvOR-0005gR-Fp for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 05:21:19 -0400 Received: by mail-pa0-f54.google.com with SMTP id wo6so12908386pac.3 for <9300@debbugs.gnu.org>; Mon, 20 Jun 2016 02:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=S7g82Xvj3kNP+9ABZABrfWDySbokugIoQBdEfNTB3ks=; b=y/7jdNSljFz0VFSe0uXt/W3uQr9V69smtlvtnvrgmA9sAEOcVtMzXpXhwAu5Si4uYc UwCd9hhak4y0YGOxAFvMAMWqJVQY2jFVI19dTiQKjRgEx5beZii08Gc0KuO40e7cQ3GS DV7MB5e36NRl5JOksSztSq4AslLn0ytcsLE0CVrYN2pqELQeTe5Rc5eSySbaAR+TVamf TYpZhAXsyrf6GgWHPFRmLU0nqS6GNSgYVUnJfjDKwt4ilbGu1heRlxoDW0SlylgQNrUv wYQijHIJLyp2Pz3PqDkioDLj9xanWkUFZOs1rB25rha74o4+tjNlM5CR91MrpW8nY/tZ N6pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=S7g82Xvj3kNP+9ABZABrfWDySbokugIoQBdEfNTB3ks=; b=XpG9DaoNdtx++jN30ptrClPeLYgF5E/IUw3kq/W8OvPTepsG82ToE9yZTXEun2kEO6 8tWjdwv7t/XPlrpetCWxHtv8iob4fXYpCsf4yv5GCa/IcozfXoKzhhxGNAYCBT6DS9lA CEixQwgSjgMs7YvDelkI1E1WAXWV6f1weEcu5uSD7hBI0nilEesNHXkdAYjP2AomfZuP dcLw/ywBNKjcAYZZ8r5+ILI9wdrPfXuUgQkwHheh7hy2TPN4qYTHar9rWRhrDvuRINDq 0d0bkv0TmMrlLVUy2y5vGNu7RTar6SOSYx6JDUp+OWPVvQl2ZGp+QcTaWz3Gl2vGAj1Y y7LA== X-Gm-Message-State: ALyK8tKAzohewL1ylwFE5dmQAgfyaYZPkRq5sbR/1huMNqF0Z5H2mhypXf4PVnU1jZ23hA== X-Received: by 10.66.27.136 with SMTP id t8mr21137687pag.108.1466414472813; Mon, 20 Jun 2016 02:21:12 -0700 (PDT) Received: from [192.168.1.51] (softbank126103144234.bbtec.net. [126.103.144.234]) by smtp.gmail.com with ESMTPSA id c8sm64010054pfb.33.2016.06.20.02.21.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 02:21:12 -0700 (PDT) To: 9300@debbugs.gnu.org From: Tino Calancha Subject: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Message-ID: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> Date: Mon, 20 Jun 2016 18:21:09 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, drew.adams@oracle.com, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Consider following code: emacs -Q: C-x b foo RET M-: (insert "(foo bar)") I) M-: (bounds-of-thing-at-point 'sexp) RET => (1 . 10) II) M-: (bounds-of-thing-at-point 'list) RET => (10 . 10) III) M-: (thing-at-point 'sexp) RET => "(foo bar)" IV) M-: (thing-at-point 'list) RET => "" V) M-: (save-excursion (goto-char 1) (bounds-of-thing-at-point 'list)) RET => (1 . 10) VI) M-: (save-excursion (goto-char 1) (bounds-of-thing-at-point 'sexp)) RET => (1 . 10) * I agree with Drew that there is neither sexp nor list at point, so i would expect I), II), III) and IV) returning nil. * Both function names, i.e., functions at I) and III), and their doc strings looks clear: return THING at point (III) or return the locations of THING at point. If there is no such THING at point i would expect both return nil: IMO that would be more consistent/intuitive with the func. names and doc strings. * I) and II) agree but III) and IV disagree. I would expect III) and IV) returning the same value. In GNU Emacs 25.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.20.6) Repository revision: 9341142dc876f4d93c442242206a7d2d40fd03af From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 08:53:53 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 12:53:53 +0000 Received: from localhost ([127.0.0.1]:47191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEyi9-0003iS-9R for submit@debbugs.gnu.org; Mon, 20 Jun 2016 08:53:53 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEyi7-0003iF-8c for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 08:53:51 -0400 Received: by mail-wm0-f54.google.com with SMTP id r201so60468910wme.1 for <9300@debbugs.gnu.org>; Mon, 20 Jun 2016 05:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hpOY1l00tvEgys6cYjeKHj1l21NHqXoZg54gPpdb29s=; b=akX45UnVSypwopBD/eC8bw1yEZzbqze8YPnUCHmtFYfuEeSnnDYXg9yRlt82HtviDe 6m+JJIvj/1TmlHiYemvd5YDTK6VceY5zEGLyk3j0bNZg5Mxlj+eQCclMY98dvZg93KHr 18NeCihTgKA1riW5CN/1hwXJES7SiotpwsDv5oSJaQ9r2HGhPz6g2GQvpjJQ5zV/HrEP 9AvzC+mlJk3HcjDVsFnxpt5mrc8WSoANYdIpKYCA6mmzi5wJ8JFT0TKI4PAKnvwBwCHa afSNauNmoPq357f5cPrGWF18FixQogZMXJ/5FJ7AGrzv16sOzw5AKBCtbuj62h815P9l 5k+A== 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:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hpOY1l00tvEgys6cYjeKHj1l21NHqXoZg54gPpdb29s=; b=XIemezpr0ahYb2KqEqeLXiPJarfI7iA2a+UpXPirfaadmYbjNMaqAK4pBSJamTOnIS gwtQqvoMsQME+Vhat3wtOWsg2UN5cXYh0Na6rSYpI69hGVicL3P0j8trrmVYFLmYCPpI P4uE0PICwbGWqYBTUIBzjcD4xG0e3QzpcDpVZC4FT/s1v1ANKKcdbfeavfKnzcxXLnei NN+PLNSH20IulnLMwkNSVQb3tmIBm/ypy1AmZXA5PVNRQ73/nFLvDYBO+XZjpBrzylfC JpWWoCTP8H93PGOLT8QkgTT0D5O6HaEwMW6GrSQUQW1B13s5p1p0noMUH30kOQpM/Tqz Y2yw== X-Gm-Message-State: ALyK8tIaZdxnEhpe/g8on2BiiqGSIEGFQWeQ0zjVO1zKizRtcdwxQMml1En5mzjyUSXCIg== X-Received: by 10.28.217.146 with SMTP id q140mr11499870wmg.56.1466427225419; Mon, 20 Jun 2016 05:53:45 -0700 (PDT) Received: from [192.168.1.2] ([185.105.173.135]) by smtp.googlemail.com with ESMTPSA id p6sm5992741wme.22.2016.06.20.05.53.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jun 2016 05:53:44 -0700 (PDT) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Tino Calancha , 9300@debbugs.gnu.org References: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> From: Dmitry Gutov Message-ID: <9eb02106-1de7-e21f-4955-cf90065f5150@yandex.ru> Date: Mon, 20 Jun 2016 15:53:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 06/20/2016 12:21 PM, Tino Calancha wrote: > * I agree with Drew that there is neither sexp nor list at point, > so i would expect I), II), III) and IV) returning nil. It's a matter of definition. If we say there is, then there is. We could also add a variable, of course. > * I) and II) agree Do they? > but III) and IV disagree. > I would expect III) and IV) returning the same value. Agree. But will you be satisfied if they both return "(foo bar)"? From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 09:11:50 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 13:11:50 +0000 Received: from localhost ([127.0.0.1]:47206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEyzV-00048w-Ul for submit@debbugs.gnu.org; Mon, 20 Jun 2016 09:11:50 -0400 Received: from mail-pf0-f173.google.com ([209.85.192.173]:36778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEyzT-00048i-SR for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 09:11:48 -0400 Received: by mail-pf0-f173.google.com with SMTP id t190so54231845pfb.3 for <9300@debbugs.gnu.org>; Mon, 20 Jun 2016 06:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=QQIAviU3UilFiR8JLS5+uxfNBFXoX1EgLBeYivKvuXE=; b=eUY9M41DwIdbqZgiCthhw4r32belAfinx0NAwZCHk+bRr2jap70uevfkToRqOzTl5Q 35x8yZsyd1QlkPLNs77lG14ogZjIF/w8xrLMQNDXkr0eCpeKrwmT4NOEGlpWR4r69RFH 28kbEWVBQuEQli7H+ite02zEa7ydNj49fXIrq0MNSIinnjZABozGqvycAZ2TvuPhPLRw Wvs/85J7dHahLnw4sO1xLb/BoAfnUOaVbRawYvTDtGAahqRD33NQ2Kw1TsgwuqQaDMJS fUD8qGntlEnu0KDgeu0mwsraLNn9hKLq8Y4tk1vDSW51vkdsL0jq5yCbS/gyppY+rKoB P+Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=QQIAviU3UilFiR8JLS5+uxfNBFXoX1EgLBeYivKvuXE=; b=Z9Iqv3kVFSnFFDGo28/WCKNwGW4KRo4kEW0EJgeqyJ6br52Dm/uZUgTRuq9IRKR/19 AQ4dMk5dkHRYC4PA/Nr/ea6M0qa3VGy9PevcIFM1KDjwuNLX5nxzDRqZJ7ZAGbR7QnGO UCg0DAhGXd/E5U9yLGz38A65D+lEjSsttQM+PjgidiySbqriBfqv+Ql1EW7TncULsFXo Nfrx8TLaQxuQtu/h1SYPJyWsY414uXtIGsHUniGL/uMrAHB0li00dCbbM2sjp6M0aVy3 427m43HrsdDn2CguuNRsUBi7B0evmbCdAcW8tgWv1WqvtrimsKo2cyNT7gTM4FIA7YXG TOww== X-Gm-Message-State: ALyK8tJHPU3hLDiKhTZcK01Ft5zg4GsIp2B0UYkEVMpBddP3ETG5SBgG/sbLVBnsVfPa8w== X-Received: by 10.98.84.197 with SMTP id i188mr22022275pfb.43.1466428301965; Mon, 20 Jun 2016 06:11:41 -0700 (PDT) Received: from calancha-pc (softbank126103144234.bbtec.net. [126.103.144.234]) by smtp.gmail.com with ESMTPSA id qc6sm88501373pac.6.2016.06.20.06.11.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 06:11:41 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Mon, 20 Jun 2016 22:11:37 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Dmitry Gutov Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING In-Reply-To: <9eb02106-1de7-e21f-4955-cf90065f5150@yandex.ru> Message-ID: References: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <9eb02106-1de7-e21f-4955-cf90065f5150@yandex.ru> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, drew.adams@oracle.com, 9300@debbugs.gnu.org, Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > It's a matter of definition. If we say there is, then there is. We could also > add a variable, of course. Sure, definitions are free. Maybe the doc string is not clear enough: at point or right before than at point would be more precise. >> * I) and II) agree > > Do they? No they don't, sorry for that. It should read: V) and VI) agree but I) and II) disagree. It seems it depends from the point of view and how you ask. It shouldn't: or always there is a list or never. >> but III) and IV disagree. >> I would expect III) and IV) returning the same value. > > Agree. But will you be satisfied if they both return "(foo bar)"? I am sure you know my answer :-) Regards, Tino From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 10:49:53 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 14:49:53 +0000 Received: from localhost ([127.0.0.1]:47834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0WP-0008Cx-Hz for submit@debbugs.gnu.org; Mon, 20 Jun 2016 10:49:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0WN-0008Ck-KW for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 10:49:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF0WG-0007dX-Hu for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 10:49:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF0W1-0007Yx-AW; Mon, 20 Jun 2016 10:49:29 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3434 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bF0Vz-0000YU-Bu; Mon, 20 Jun 2016 10:49:27 -0400 Date: Mon, 20 Jun 2016 17:48:34 +0300 Message-Id: <8337o79arh.fsf@gnu.org> From: Eli Zaretskii To: Tino Calancha In-reply-to: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> (message from Tino Calancha on Mon, 20 Jun 2016 18:21:09 +0900) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Tino Calancha > Date: Mon, 20 Jun 2016 18:21:09 +0900 > Cc: f92capac@gmail.com, dgutov@yandex.ru > > * I agree with Drew that there is neither sexp nor list at point, > so i would expect I), II), III) and IV) returning nil. 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 13:50:37 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 17:50:37 +0000 Received: from localhost ([127.0.0.1]:47985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF3LJ-0007Hc-5v for submit@debbugs.gnu.org; Mon, 20 Jun 2016 13:50:37 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:34140) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF3LH-0007HO-1A for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 13:50:35 -0400 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 u5KHoSUo021511 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 17:50:28 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u5KHoS7p013487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 17:50:28 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u5KHoRvp008962; Mon, 20 Jun 2016 17:50:27 GMT MIME-Version: 1.0 Message-ID: <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> Date: Mon, 20 Jun 2016 10:50:27 -0700 (PDT) From: Drew Adams To: Eli Zaretskii , Tino Calancha Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com>> <<8337o79arh.fsf@gnu.org>> In-Reply-To: <<8337o79arh.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.7 (---) > > * I agree with Drew that there is neither sexp nor list at point, > > so i would expect I), II), III) and IV) returning nil. Tino agrees because he wants to make use of the difference between there being a THING at point and there being no THING at point but there being a THING at (1- (point)). > 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. The proper thing to do is to: 1. Fix this bug. It is a real bug. 2. Add a new function that provides the same behavior as the broken behavior that is current, or similar. And call it "-near-point", not "-at-point". More precisely, for #2 the use case you cite is only to maximize grabbing a thing at or _near_ point. In the case of the current code, that means at point or at (1- (point)). If all you care about is grabbing something at either of those positions then the code works for you. If you try to use it more generally, it is broken. IOW, if you actually care about the difference between point and (1- (point)) then you are out of luck. A better, more general, near-point function looks farther from point, up to some caller-specified distance (horizontally and vertically). That's the purpose, in my code, of variables `tap-near-point-x-distance' & `tap-near-point-y-distance' and function `tap-bounds-of-thing-nearest-point' (prefix `tap-' for library `thingatpt+.el'). See the arguments given in the bug thread for why #1 is important - why `bounds-of-thing-at-point' should be fixed as indicated. It is important that one be able to use `bounds-of-thing-at-point' and `thing-at-point' in a way that is accurate, precise, and general, and not only to try to grab something that is near point. In particular, this matters when the functions are used programmatically to handle successive THINGs (of the same type) in a buffer or region. For that, there needs to be a clean boundary between THING and no THING at a given position. You need to be able to test whether there is actually a THING at point. I've spent a lot of time with this code, and with a fixed version of it, over the years. My use cases go beyond just trying to come up with a default value for a minibuffer read. That doesn't seem to matter to those in charge here. Too bad, but so be it. I'll continue to use my code (`thingatpt+.el'), so not fixing this bug doesn't affect me much, directly. But it does affect me, and it affects others too. For me, it means that other code, which makes use of this fix, must also conditionally handle the case where a user does not have `thingatpt+.el', even if the result is inadequate. I recommend to users of my code that makes use of thing-at-point features that they also use library `thingatpt+.el', but I try to let that other code have some semi-workable fallback behavior for the case where they do not use `thingatpt+.el'. So yes, this is an added (and unnecessary) burden for me and for users of my code. But I've been dealing with it for years, so it's nothing new. The real loss, if you do not fix this bug, is for Emacs users who do not use `thingatpt+.el'. They will be unable to do things with the `thing-at-point' code that they should be able to do, simply because it is broken at the end-of-thing boundary. But it has proven to be impossible to convince you to apply this simple fix. So be it. I can only repeat that the proper solution is to fix this bug and to also give users a new function that does what you and they currently expect of `thing-at-point', for the use case of providing a default value for something: be able to grab a thing at or near point. `thingatpt+.el' has existed since 1996, yet you argue that even though the thingatpt.el code has this bug, it should not be fixed because users (or you) are used to it. "Your reasoning seems valid, however by now this behavior is ingrained into my expectations of how thing-at-point should behave." Your expectations come from using the code only to grab a default value from the text. You don't care about testing for a thing at point. You want grabbing text to work even when there is no THING at point but there is a THING at (1- (point)). It would be simple enough to tell users to use the new function that gives you a thing at or _near_ point, if they want only to retrieve some text to use as a default value. You make changes all the time to Emacs code that necessitate 3rd-party code using (if (fboundp 'AAA) BBB CCC) tests. This would be no different. And the function names would be more correct: "-at-point" would really mean at point, and the behavior you expect would be properly named "-near-point". This bug has been declared "minor", but it is not - it makes the thing-at-point code unusable in a general and precise way. The fix, however, is trivial. The pushback from you is major. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 14:34:03 2016 Received: (at submit) by debbugs.gnu.org; 20 Jun 2016 18:34:03 +0000 Received: from localhost ([127.0.0.1]:47990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF41K-0008GP-QL for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:34:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF41J-0008Fv-UL for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:34:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF41D-0007Tg-5F for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:33:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF41D-0007TR-22 for submit@debbugs.gnu.org; Mon, 20 Jun 2016 14:33:55 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF41A-000512-GV for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:33:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF415-0007SE-G4 for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:33:51 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:57207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF415-0007S3-5H for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 14:33:47 -0400 Received: from [192.168.178.35] ([77.12.77.196]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0MLyNI-1bILo50SNQ-007iSj for ; Mon, 20 Jun 2016 20:33:45 +0200 Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: bug-gnu-emacs@gnu.org References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: <414ccabd-9198-6ae0-594c-e6014e85de75@easy-emacs.de> Date: Mon, 20 Jun 2016 20:38:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:aAcdx6G0h7RwQ3yXugvBhEvBEnikNls5b/NMwpPtQSfwL7RQgfx i+23UG9/l4taZuO8xd6igNpXzRkqtxVK+3dgcLsqqK4zGnwPzexcslMz+xL2Myoh5TQapXO ipHcFK8Huv9WPhE7syqhltAtru2/XJf1Zzg/2W05wfDY6ZBUfbHtSqjaOW2+OKuTsyDiZpv G64JXP/aT/j0x4Q2r3okw== X-UI-Out-Filterresults: notjunk:1;V01:K0:XJ3GNbZRY+A=:ivKnUd8tHNzbAB1+qm7Jho 7UMnsQEVJJCFdxeZS/MiLWMiWvbqWuBYS0/ohTq05be1pFQK6MDCKAV5akNe+xm7o1woAqm2j 1B4tyWlVkgo6Yfoq6zsv/4gBEMNcDH7suTqcMhaQzcMR08iXa0qiHmt+QZV0BYIJJz+DSQAkE AFnpgU0SCo45LDv27aq+uNVlTrhaZIwOwfvw/5gZsRcPufX1RMXuOiiOIU8YvxS/SQyIWKxwp BdgdJLjyp8a0iEdgb8AUWSN5P68y5KpmQgX7KX5VY7MrN6O2pMJ5C9wYu5787CuunyTgxnT6u 3GlCIiIzW3CvBYUtQX677CzF4FCEZxEuMjdN/rIGtKuWPUM8hAd71M+ISfKvJx8FILb8aXvd7 ewcPGTOaimw5gap1poyagYRT83LTiHMgdE9Yo7qG1bwy8qY/Wfo0Nm0e1BqMRZA1868wXdKMi AFAM2XZSLQ4W8lOBb6lKDKvnNARyZAYSVQy/hF/4JpYohUSma0VkVpvAD4hupVhZI9lyVbrWA zzwrXW8rrI6QmvIkLn4gfqdc5zofl15aDIPA3NLO9unLkc9+ADWidkXR7XEhv7ytkV/qRFwQE HEbKMJH47jEF0ZPkmRve8GE/ZdjZWxIle7zaZ/MhjJown9iCSh57u6+SYvIKSRk95SB0KQxKj f8L6Q4q5c3a21R5EB7Tx+lXJPGDDfr2AlplrRwAUb7DrkNqfM+v8+sOBAzfICOaaECFbt69B5 CJv7TCYZRYnlCq+B X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 20.06.2016 19:50, Drew Adams wrote: >>> * I agree with Drew that there is neither sexp nor list at point, >>> so i would expect I), II), III) and IV) returning nil. > Tino agrees because he wants to make use of the difference between > there being a THING at point and there being no THING at point but > there being a THING at (1- (point)). > >> 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. > > The proper thing to do is to: > > 1. Fix this bug. It is a real bug. > > 2. Add a new function that provides the same behavior as the > broken behavior that is current, or similar. And call it > "-near-point", not "-at-point". > > More precisely, for #2 the use case you cite is only to maximize > grabbing a thing at or _near_ point. In the case of the current > code, that means at point or at (1- (point)). If all you care > about is grabbing something at either of those positions then the > code works for you. If you try to use it more generally, it is > broken. IOW, if you actually care about the difference between > point and (1- (point)) then you are out of luck. > > A better, more general, near-point function looks farther from > point, up to some caller-specified distance (horizontally and > vertically). That's the purpose, in my code, of variables > `tap-near-point-x-distance' & `tap-near-point-y-distance' and > function `tap-bounds-of-thing-nearest-point' (prefix `tap-' for > library `thingatpt+.el'). > > See the arguments given in the bug thread for why #1 is important - > why `bounds-of-thing-at-point' should be fixed as indicated. > > It is important that one be able to use `bounds-of-thing-at-point' > and `thing-at-point' in a way that is accurate, precise, and > general, and not only to try to grab something that is near point. > > In particular, this matters when the functions are used > programmatically to handle successive THINGs (of the same type) > in a buffer or region. For that, there needs to be a clean > boundary between THING and no THING at a given position. You > need to be able to test whether there is actually a THING at > point. > > I've spent a lot of time with this code, and with a fixed version > of it, over the years. My use cases go beyond just trying to come > up with a default value for a minibuffer read. > > That doesn't seem to matter to those in charge here. Too bad, but > so be it. I'll continue to use my code (`thingatpt+.el'), so not > fixing this bug doesn't affect me much, directly. > > But it does affect me, and it affects others too. For me, it > means that other code, which makes use of this fix, must also > conditionally handle the case where a user does not have > `thingatpt+.el', even if the result is inadequate. > > I recommend to users of my code that makes use of thing-at-point > features that they also use library `thingatpt+.el', but I try to > let that other code have some semi-workable fallback behavior for > the case where they do not use `thingatpt+.el'. > > So yes, this is an added (and unnecessary) burden for me and > for users of my code. But I've been dealing with it for years, > so it's nothing new. > > The real loss, if you do not fix this bug, is for Emacs users who > do not use `thingatpt+.el'. They will be unable to do things with > the `thing-at-point' code that they should be able to do, simply > because it is broken at the end-of-thing boundary. > > But it has proven to be impossible to convince you to apply this > simple fix. So be it. > > I can only repeat that the proper solution is to fix this bug > and to also give users a new function that does what you and they > currently expect of `thing-at-point', for the use case of > providing a default value for something: be able to grab a thing > at or near point. > > `thingatpt+.el' has existed since 1996, yet you argue that even > though the thingatpt.el code has this bug, it should not be > fixed because users (or you) are used to it. > > "Your reasoning seems valid, however by now this behavior is > ingrained into my expectations of how thing-at-point should > behave." > > Your expectations come from using the code only to grab a > default value from the text. You don't care about testing for > a thing at point. You want grabbing text to work even when > there is no THING at point but there is a THING at (1- (point)). > > It would be simple enough to tell users to use the new function > that gives you a thing at or _near_ point, if they want only to > retrieve some text to use as a default value. > > You make changes all the time to Emacs code that necessitate > 3rd-party code using (if (fboundp 'AAA) BBB CCC) tests. This > would be no different. And the function names would be more > correct: "-at-point" would really mean at point, and the > behavior you expect would be properly named "-near-point". > > This bug has been declared "minor", but it is not - it makes > the thing-at-point code unusable in a general and precise way. > The fix, however, is trivial. The pushback from you is major. > > > +1 From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 16:06:25 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 20:06:25 +0000 Received: from localhost ([127.0.0.1]:48052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF5Si-0001xq-O7 for submit@debbugs.gnu.org; Mon, 20 Jun 2016 16:06:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF5Sh-0001xb-Ai for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 16:06:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF5SY-00019g-0u for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 16:06:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF5SN-00017I-Cj; Mon, 20 Jun 2016 16:06:03 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3808 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bF5SJ-0007kW-Bt; Mon, 20 Jun 2016 16:06:01 -0400 Date: Mon, 20 Jun 2016 23:04:50 +0300 Message-Id: <83twgn7hjx.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> (message from Drew Adams on Mon, 20 Jun 2016 10:50:27 -0700 (PDT)) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com>> <<8337o79arh.fsf@gnu.org>> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, dgutov@yandex.ru, 9300@debbugs.gnu.org, tino.calancha@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > Date: Mon, 20 Jun 2016 10:50:27 -0700 (PDT) > From: Drew Adams > Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru > > > 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. That's immaterial. It is being used in many places, and it's obviously useful. Somewhere in this long discussion there was a suggestion to add new functions that behave like you want. I suggest to invest energy in that direction, instead of more bikeshedding. 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 19:34:59 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 23:34:59 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: Date: Mon, 20 Jun 2016 16:34:46 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: << <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com>>> <<<8337o79arh.fsf@gnu.org>>> <<0e2c9c67-12a2-4712-92d2-e3c204f46838@default>> <<83twgn7hjx.fsf@gnu.org>> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, dgutov@yandex.ru, 9300@debbugs.gnu.org, tino.calancha@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.7 (---) > > > 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'. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 19:59:47 2016 Received: (at 9300) by debbugs.gnu.org; 20 Jun 2016 23:59:47 +0000 Received: from localhost ([127.0.0.1]:48174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF96Z-0007Kg-6y for submit@debbugs.gnu.org; Mon, 20 Jun 2016 19:59:47 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:34238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF96W-0007KS-Qr for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 19:59:45 -0400 Received: by mail-ob0-f173.google.com with SMTP id ru5so240185obc.1 for <9300@debbugs.gnu.org>; Mon, 20 Jun 2016 16:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=h+i9mM0s0JeoGiqSln8xEJch7x7rv1TjbJABFKqH3Is=; b=jTfjkIhUNjRgWQUaqSqX43XPY1t3dlY3tvy9hBkOsDEbEHCOIQoj7trJnBETOvHagy 1VHmvffGjvotO+Fj4QtDmCloBzlylxjZXT9dR5A4ENssxmWtkzfVAtQpgwly9vhh8M7A WngaNpASjK7EXex3DqVnutwog5JLh8lBejfYVvU7lK7DUlKDIdaQURVYo3trSWdMiLkU eIs0xJVJXCSwDWwUVECo4w3uRomZAuSZJUBS7UKW024DV2rAPljT547GFYHnsai0OQKR G+LI43DszeS8Sy8sR/+lNSukbscNDYd5rveblqxN2qTV0SitoIWtXIJMXMMyjH5vC+C1 b7Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=h+i9mM0s0JeoGiqSln8xEJch7x7rv1TjbJABFKqH3Is=; b=jMkY9ZjQFQZuQ6TL6/MEPnquXM6f27MJeKumXDFGwqBYVn2o/fbqM2bIAOzHXLXX1G /R5C5eruCzE2neAh56AXkVJsL/iA+PvkPXc448/fM9zbpChe3KniJq+nI5P+Jsc1+elB c5zRUVgI/v2PvtO6lQFH123J+fOiKNE3eqb3iYlfEjWYaj7a920YSOvJtJXO5oojnVe1 jIIleDgw41RpzOk0fg9yybakdwBjBxrkDbBp0J3ZbMjPi6p6Z6QRQ5sABTn/o5ECiAKT b5ifDKhKvxNTDAyqmBE/VEvrFEtWzYlvbI2CdXo52wzsPIy1cJ3k5w7twt7aqxHJZ6rm edbA== X-Gm-Message-State: ALyK8tK6vMb2aimzHQe/bAR6N0RpEiguxR7WB3eRLgHWJuKgN9w3CA3EtpzCjhFpfoE+NdhknnA9D+JsnZy2QQ== X-Received: by 10.157.22.179 with SMTP id c48mr13143452ote.35.1466467174045; Mon, 20 Jun 2016 16:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.238 with HTTP; Mon, 20 Jun 2016 16:59:33 -0700 (PDT) In-Reply-To: References: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> From: Noam Postavsky Date: Mon, 20 Jun 2016 19:59:33 -0400 X-Google-Sender-Auth: 96dtuyBG3br5XpGP8ZOU5wheXVQ Message-ID: Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Drew Adams Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, Eli Zaretskii , Brief Busters , 9300@debbugs.gnu.org, tino.calancha@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Isn't the safest and simplest solution to rename the current *-at-point to *-near-point, keep the *-at-point names as obsolete aliases, and add new *-precisely-at-point functions with the definitions from the thingatpt+ library? That way, current users of *-at-point who happen to be relying the on *-near-point functionality won't break. Only downside I can see is a slightly longer name for the *-precisely-at-point callers, but that doesn't seem too bad. What you do think? From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 20:47:41 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 00:47:41 +0000 Received: from localhost ([127.0.0.1]:48185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF9qv-0008RW-9F for submit@debbugs.gnu.org; Mon, 20 Jun 2016 20:47:41 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:26718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF9qt-0008RJ-Jo for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 20:47:40 -0400 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 u5L0lWYU001505 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jun 2016 00:47:32 GMT 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 u5L0lVL3000684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 00:47:32 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u5L0lTTp005796; Tue, 21 Jun 2016 00:47:30 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 20 Jun 2016 17:47:27 -0700 (PDT) From: Drew Adams To: Noam Postavsky Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, Eli Zaretskii , Brief Busters , 9300@debbugs.gnu.org, tino.calancha@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.7 (---) > Isn't the safest and simplest solution to rename the current > *-at-point to *-near-point, keep the *-at-point names as obsolete > aliases, and add new *-precisely-at-point functions with the > definitions from the thingatpt+ library? That way, current users of > *-at-point who happen to be relying the on *-near-point functionality > won't break. Only downside I can see is a slightly longer name for the > *-precisely-at-point callers, but that doesn't seem too bad. >=20 > What you do think? That's possible (and I appreciate your trying to find a diplomatic way to get this bug fixed), but I don't think that is the best approach. We should aim to have a reasonable name, not just something that doesn't conflict. There is little sense in abandoning the most reasonable name for this, IMO. This is what the library is intended for: returning a thing at point. If the name "*-at-point" is kept (for behavior that is really at point) then the worst that will happen is that some users might complain that they no longer get a thing that is before point but not also at point. And that won't even happen for distributed Emacs code, which should replace any appropriate calls to *-at by *-near (where appropriate means that you really do want to retrieve the thing before point as well as the thing at point). This is a simple off-by-one bug. It really should not require anything to be deprecated. Just because someone might have gotten used to the bugged behavior is not a good reason not to fix this bug. If going the direction you suggest is the best compromise that can be had, I'd suggest using the name *-at-pt instead of *-precisely-at-point. IOW, just change "point" to "pt". That's not the fix I prefer, and it hurts discoverability (matches against "point"), and it doesn't jibe with names such as `find-file-at-point', but I think it's better than something as artificial as *-precisely-at-point. That name just makes one wonder. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 23:01:28 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 03:01:28 +0000 Received: from localhost ([127.0.0.1]:48214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFBwO-00033m-3s for submit@debbugs.gnu.org; Mon, 20 Jun 2016 23:01:28 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:34115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFBwM-00033Y-3g for 9300@debbugs.gnu.org; Mon, 20 Jun 2016 23:01:26 -0400 Received: by mail-pa0-f42.google.com with SMTP id bz2so1425560pad.1 for <9300@debbugs.gnu.org>; Mon, 20 Jun 2016 20:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=soV7xCBwMb5SPSmjXMwIc+UhbZXx/rPAqEd7au1GAOs=; b=QR52fNAx+6ZKBOwG6/Zw5PMiLi2uy1g2qe+4N/Epc2VkghiF7ynmht3f7cieqLGqTg Q4S0omQx1Darw/Xv2uKynzE8qJOil6TuJGY+hqMlFP9X/c6iHXwLBW+KMvoYHcyGCR4r FcZOIMuTWS0jx2GkMQKLDkQYX0mUxwuHjxbelekLRohyYbGc9DRypi9aOK2D3O+rCDgs ixQ9pCYTXHrNoAIOhhTU00m+xwcejyuRe9HdNJUNZMOawCS7FC2ay0zOojN3H+THxBNr fpXwG3L9YxbRLaXPFme00vSv28DEwNhYcM9SUYKLbfpDQU0JkDYceGzyZuWduSaTWMUq MIQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=soV7xCBwMb5SPSmjXMwIc+UhbZXx/rPAqEd7au1GAOs=; b=hK9sKFoxOEuK/LMnirjNp4ltPxOM16dekgfxzau0FjIaUH+IZpyJ2L6ByaxTSXe+3F n9DL31BLml6WE1vNWa5RnrcBBJk0GWXBU2w3FOdnFbEYG1BpkSTBjlNiZBQmiB4mEfeK f9W9wGTJp56z6NPsDZZbySISg+EBOsdgd29ZrGVubVWVRsWzqSSp7yZd5LS6WKFhwOED kvUcEwndsXJou7aAh3n2QhswIVeshCPauz0k5+SbWkjgFCDRtzjE6ZJE+V0LETDmANKb q9M9oJef7T5iGdN2OkBZsgcHiEfYCFIdH1vZJGdWM1STM7//Uy70N4L5YsxeWUHINjSY 0avQ== X-Gm-Message-State: ALyK8tL5vTsbX0SZSFRyqhWTGoRutrvWjDHklCKw6cWExB4DE94cR5do0BPkuYrFDO8Zbw== X-Received: by 10.66.171.202 with SMTP id aw10mr25610749pac.100.1466478080117; Mon, 20 Jun 2016 20:01:20 -0700 (PDT) Received: from [192.168.1.51] (softbank126103144234.bbtec.net. [126.103.144.234]) by smtp.gmail.com with ESMTPSA id ab6sm21204854pad.44.2016.06.20.20.01.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 20:01:19 -0700 (PDT) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Eli Zaretskii References: <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <8337o79arh.fsf@gnu.org> From: Tino Calancha Message-ID: Date: Tue, 21 Jun 2016 12:01:16 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <8337o79arh.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 9300 Cc: f92capac@gmail.com, npostavs@users.sourceforge.net, 9300@debbugs.gnu.org, drew.adams@oracle.com, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > 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. * If the behaviour is obviously correct the funcs. are easier to use. * If the definition allows for more general uses, as Drew explained, much better. * For code where the existence of the THING (exactly) at point really matters, the current behaviour may cause undesirable effects: * Karen Lisp, the mother of 8 yr old Emily, is enjoying a family cruise. * Karen just downloaded in her favourite iTHING one new APP based on 'thingatpt: - It shows an alert whenever there is _no_ a boat at point. - The point equals Emily position. * The ship is not moving: they throw the anchor during the Hawaiian dance show, which Karen is watching while Emily went to play. 1) First, Emily went to the prow to receive some fresh air. => App: no alert 2) Later, Emily went to the middle of the ship following one cat. => App: no alert 3) Finally, she went to the stern to see the dolphins. => App: no alert 4) While Emily was feeding the dolphins with her cheeseburger, she fell down to the water. => App: no alert!!! I) Hopefully Emily knows how to swim. II) Emily would be OK if (thing-at-point THING) return nil whenever there is no THING at point. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 02:10:21 2016 Received: (at submit) by debbugs.gnu.org; 21 Jun 2016 06:10:21 +0000 Received: from localhost ([127.0.0.1]:48414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFEt7-0007em-8S for submit@debbugs.gnu.org; Tue, 21 Jun 2016 02:10:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44876) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFEt4-0007eY-9G for submit@debbugs.gnu.org; Tue, 21 Jun 2016 02:10:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFEsx-0008G4-VT for submit@debbugs.gnu.org; Tue, 21 Jun 2016 02:10:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:44050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFEsx-0008Eb-SI for submit@debbugs.gnu.org; Tue, 21 Jun 2016 02:10:07 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFEsv-0003fk-AN for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2016 02:10:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFEsq-0008DU-FI for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2016 02:10:05 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:52003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFEsq-0008DG-4k for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2016 02:10:00 -0400 Received: from [192.168.178.35] ([77.12.1.85]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0MDxlf-1bAZlx4BLT-00HNXj for ; Tue, 21 Jun 2016 08:09:59 +0200 Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: bug-gnu-emacs@gnu.org References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> <83twgn7hjx.fsf@gnu.org> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: Date: Tue, 21 Jun 2016 08:14:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <83twgn7hjx.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:A3oGbTSnMHruCH/jVajd55Wn1ASb9hxLgH/07lEO+V2rFLWzDNM qei2vYiycfnq/N5NYlPK5ESBfEldmXDhTAwDbzfIlGZt0HdmfTFGYSuv+uila9wjIyUhCq2 SbRGY1lNwta6yJqXbbdsx/IuxJXJbyZ9Z0o3eRaF2H++D7TG59di4dKG9gDsSMTW91cz09O frl/0yWd3S2JD6ZF/FQWw== X-UI-Out-Filterresults: notjunk:1;V01:K0:r5r6N2IoSD4=:0qaozZuqmogz7TEKNFvd/J DpjIwVRBsL1WsFQTV+RGucgqo+caI78zw8bxL2okWf2wwg9W0TQoLreH2ea+JdevAwSzL5Nw5 IccwlPV3WvX03QMHp8jgIzwN0Yem284vnwlN5HOmSzNqkxokrAjgtM1uQwNj+SSvnIFNtsb1g FsbxymWqQd9JOdKMDCA6MTpsjIowR1O7Cs4igZ6IFxSwf/JBBw+LYLcUFBc3pwRhxtzzM55P9 G8v8DDcYEOi5E+hxqS+AVSOPwruxnnt9fowfKGmRU2lTx/cmHU7Zf8noLVs9UUZNb1vNhnYlI X5VdJJxJhrH/d/UcPkpmUHUxoAjVTlHawimZyAMCoI/85B409USfl5p14n6qZpIDpHP3qAnB5 GVuyOguVw3tGjPlb/jJJBDZdP1bb7Fsl9hUh9IREmtlAjyNcKnhAvubNsEVoMebPxNgdY14oA mgJCRtZ87/IgB/3FBuSZpff+QYfiUyFohdFFsrxJcuCMv0gL+BHHTA3fYbn0BK0UUWS58PkBZ EmZ/JNDDdNqX9ysOOBsajIang58OMsulYTSS8C/mzp1ZXng8iul26bBSAkE5AvSVEAoHEHjv7 poiu7Vp1NRDqQeymdJGaoheWeF+/PGF7cYpEttgfsunl+x/VBCNdfVUlLEJa7oUeLwwp0uM7d 1bPtGhb5z3XxqdDQzL48fqcvVydWZPaKnR7NqmSa9tSrs+n9zvPLDJzMlz7YCjcRcc+1Z6wPr Qnj3ce550LhGYSCr X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 20.06.2016 22:04, Eli Zaretskii wrote: >> Date: Mon, 20 Jun 2016 10:50:27 -0700 (PDT) >> From: Drew Adams >> Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru >> >>> 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. > That's immaterial. It is being used in many places, and it's > obviously useful. It is useful, but not in the way of the lemma "at-point". At-point means at cursor-position. What is expected when calling "C-x =" -- probably not info WRT char after, but at cursor position. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 08:51:17 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 12:51:17 +0000 Received: from localhost ([127.0.0.1]:48740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFL97-0002aK-LJ for submit@debbugs.gnu.org; Tue, 21 Jun 2016 08:51:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFL95-0002a5-Ne for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 08:51:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFL8x-000540-C4 for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 08:51:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFL8x-00053w-92; Tue, 21 Jun 2016 08:51:03 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4726 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFL8w-0000ih-Du; Tue, 21 Jun 2016 08:51:02 -0400 Date: Tue, 21 Jun 2016 15:50:11 +0300 Message-Id: <83k2hi7lks.fsf@gnu.org> From: Eli Zaretskii To: Andreas =?windows-1252?Q?R=F6hler?= In-reply-to: (message from Andreas =?windows-1252?Q?R=F6hler?= on Tue, 21 Jun 2016 08:14:22 +0200) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> <83twgn7hjx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 9300 Cc: 9300@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Andreas Röhler > Date: Tue, 21 Jun 2016 08:14:22 +0200 > > On 20.06.2016 22:04, Eli Zaretskii wrote: > >> Date: Mon, 20 Jun 2016 10:50:27 -0700 (PDT) > >> From: Drew Adams > >> Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru > >> > >>> 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. > > That's immaterial. It is being used in many places, and it's > > obviously useful. > > It is useful, but not in the way of the lemma "at-point". At-point means > at cursor-position. Yes, the de-facto behavior is actually "at or around point". From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 09:03:38 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 13:03:38 +0000 Received: from localhost ([127.0.0.1]:48756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLL8-0002u7-3S for submit@debbugs.gnu.org; Tue, 21 Jun 2016 09:03:38 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:55789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLL5-0002tr-H4 for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 09:03:37 -0400 Received: from [192.168.178.35] ([77.12.1.85]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0MOmZe-1bLNUE3Pmg-0065FM; Tue, 21 Jun 2016 15:03:29 +0200 Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING To: Eli Zaretskii References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> <83twgn7hjx.fsf@gnu.org> <83k2hi7lks.fsf@gnu.org> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: <37a9ccfc-35f9-b8a4-77c9-61a6c3cd02bc@easy-emacs.de> Date: Tue, 21 Jun 2016 15:07:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <83k2hi7lks.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:E5xZecIpJs2k3YXAqJIbBO0YjTrguRRYXAX/T/jMHlcMVBOTBH9 j0P4aPMD0Y0z7tSQy3DmYLGJYPBAne7zIRJgeSvCw860iiQkzghnbyql5CDROFam4uwk6Hq bWxSmlDj9fht0pLUsmlYJw/plYzN8Xg+QeB28hammXTm23YJrkIKgJxsQ7gpLAxiCodqzg/ 9AXStgkeZUcAQChuHKfLg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3c2dCOHhWfk=:fbd70uzTa6/w4tR45thDwC VFCW8d+CfCQztxEVutvgQsLa6JtRhBqcRqUChHO1UwVwTpn8CLjN5hzXsNwqDAd36dfpnMC5R IExWlDxPorZGTtua2h8FIbQYCLlp39g2jYyqm9W5BcFFIbXNGcOoCvZk9ggTmTk3tuuIo75m2 uWUAJXrB1tHmF/BJP3PJFvefwXgkI0cB+hm4pVJ0NEqsNmlsvw/SRPfEqwbGR+MHI9VFKl9qW lT82unydkW9jB3XqikZCZeXy3/BSiwGVCrp6XDZ4z0jTkxRX08jtr01wjdxqbhDEpgquwx87O g4a3oqvfa0fsRia8gPIxYa/VnYNMRDMdmphFyV5B9Qsuve3Xy0XSvwVKsvyhaRMoe0lwtEaHK 19t33DFaDsjs8P7ryC+OTlxPHNc3HSP4uwUQwfM8D7J7bIylhaH/X3mQdXYl6Rd+mzQVB+iXD qhMYCHTyPj2V+vNscx9jMQEzpKVOOqc20hSR+zoMsbL5EP1qmSaJgodC/LqK9dDUdAAvQ85fk 6kTOgxIzxJIVYu1aPWN3zXWYkyX+MxScDqSIoZsFR7LMUepErsi3/w11DR8wzPOz4WFMvq5/f J/0NvDLzlFUa7qqrwcXBx6GmnVEOrJCygU3R/xn9FmGMFgsxgJHVSdbKZGy4bAaWPxyNEeQhn Is+HV3XFmrwoPD3WoveK/hha8CswuEJHrRpFCDNksz7tDzPz6m4o/Ko9rNxqwLLoxfJ5rk7mw a8MWJDmFzK7KwjIR X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 9300 Cc: 9300@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On 21.06.2016 14:50, Eli Zaretskii wrote: >> From: Andreas Röhler >> Date: Tue, 21 Jun 2016 08:14:22 +0200 >> >> On 20.06.2016 22:04, Eli Zaretskii wrote: >>>> Date: Mon, 20 Jun 2016 10:50:27 -0700 (PDT) >>>> From: Drew Adams >>>> Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru >>>> >>>>> 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. >>> That's immaterial. It is being used in many places, and it's >>> obviously useful. >> It is useful, but not in the way of the lemma "at-point". At-point means >> at cursor-position. > Yes, the de-facto behavior is actually "at or around point". In what programming language users will be satisfied with results which are correct or just a little bit false? Well, assume there are some - so Emacs entered the area of AI :) From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 09:25:42 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 13:25:42 +0000 Received: from localhost ([127.0.0.1]:48806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLgU-0003WU-7M for submit@debbugs.gnu.org; Tue, 21 Jun 2016 09:25:42 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:27232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLgS-0003WH-BF for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 09:25:40 -0400 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 u5LDPX4s001882 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jun 2016 13:25:34 GMT 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 u5LDPW1o006673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 13:25:33 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u5LDPSLP006288; Tue, 21 Jun 2016 13:25:31 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 21 Jun 2016 06:25:24 -0700 (PDT) From: Drew Adams To: =?iso-8859-1?B?QW5kcmVhcyBS9mhsZXI=?= , 9300@debbugs.gnu.org Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> <83twgn7hjx.fsf@gnu.org> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: 9300 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) > >>> 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. > > > > That's immaterial. It is being used in many places, and it's > > obviously useful. >=20 > It is useful, but not in the way of the lemma "at-point". At-point > means at cursor-position. What is expected when calling "C-x =3D" > -- probably not info WRT char after, but at cursor position. Yes, but this has all been said before. Eli knows this, but it does not sway him. And at least as important is the fact that "-at-" needs to refer to only ONE POSITION, not two. Currently, the function acts the same for both point and point-minus-1. You cannot tell whether it has determined that the thing it returns is at point or at point-minus-1. But this too has all been said before, and Eli knows this too. It too has not persuaded him. It seems not to matter whether the function DTRT. The only thing that seems to matter to him is that this broken behavior has been in effect for a while. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 09:31:25 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 13:31:25 +0000 Received: from localhost ([127.0.0.1]:48818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLm1-0003gE-Es for submit@debbugs.gnu.org; Tue, 21 Jun 2016 09:31:25 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:31714) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLlz-0003fy-DF for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 09:31:23 -0400 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 u5LDVGDX010884 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jun 2016 13:31:17 GMT 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 u5LDVGMk024293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 13:31:16 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u5LDVDoL009223; Tue, 21 Jun 2016 13:31:14 GMT MIME-Version: 1.0 Message-ID: <0b1c64b7-9de7-4d67-bbbb-d1b9a7701af3@default> Date: Tue, 21 Jun 2016 06:31:12 -0700 (PDT) From: Drew Adams To: Eli Zaretskii , =?iso-8859-1?B?QW5kcmVhcyBS9mhsZXI=?= Subject: RE: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> <83twgn7hjx.fsf@gnu.org> <83k2hi7lks.fsf@gnu.org> In-Reply-To: <83k2hi7lks.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: 9300 Cc: 9300@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) > Yes, the de-facto behavior is actually "at or around point". Around only in the sense of something looser than at. Not around in the sense of before and after. To be exact, the current behavior is "at point or at point minus one". It is not "at point or at point plus or minus one". It does not test a _single_ position. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 11:14:52 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 15:14:52 +0000 Received: from localhost ([127.0.0.1]:49901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFNO7-0006Pz-Oy for submit@debbugs.gnu.org; Tue, 21 Jun 2016 11:14:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFNO5-0006Pj-Oa for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 11:14:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFNNx-0004I4-6g for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 11:14:44 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFNNx-0004Hs-3M; Tue, 21 Jun 2016 11:14:41 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4922 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFNNu-0005PS-Fe; Tue, 21 Jun 2016 11:14:39 -0400 Date: Tue, 21 Jun 2016 18:13:46 +0300 Message-Id: <83a8ie7exh.fsf@gnu.org> From: Eli Zaretskii To: Andreas =?windows-1252?Q?R=F6hler?= In-reply-to: <37a9ccfc-35f9-b8a4-77c9-61a6c3cd02bc@easy-emacs.de> (message from Andreas =?windows-1252?Q?R=F6hler?= on Tue, 21 Jun 2016 15:07:52 +0200) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> <83twgn7hjx.fsf@gnu.org> <83k2hi7lks.fsf@gnu.org> <37a9ccfc-35f9-b8a4-77c9-61a6c3cd02bc@easy-emacs.de> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 9300 Cc: 9300@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > Cc: 9300@debbugs.gnu.org > From: Andreas Röhler > Date: Tue, 21 Jun 2016 15:07:52 +0200 > > >> It is useful, but not in the way of the lemma "at-point". At-point means > >> at cursor-position. > > Yes, the de-facto behavior is actually "at or around point". > > In what programming language users will be satisfied with results which > are correct or just a little bit false? Emacs does this all the time. It's called DWIM. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 11:17:09 2016 Received: (at 9300) by debbugs.gnu.org; 21 Jun 2016 15:17:09 +0000 Received: from localhost ([127.0.0.1]:49909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFNQL-0006UX-DH for submit@debbugs.gnu.org; Tue, 21 Jun 2016 11:17:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60657) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFNQJ-0006U5-BN for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 11:17:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFNQB-0004nf-Jk for 9300@debbugs.gnu.org; Tue, 21 Jun 2016 11:17:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFNQB-0004nS-GW; Tue, 21 Jun 2016 11:16:59 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4924 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFNQ9-0005q5-6c; Tue, 21 Jun 2016 11:16:57 -0400 Date: Tue, 21 Jun 2016 18:16:06 +0300 Message-Id: <837fdi7etl.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: <0b1c64b7-9de7-4d67-bbbb-d1b9a7701af3@default> (message from Drew Adams on Tue, 21 Jun 2016 06:31:12 -0700 (PDT)) Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: < <67e48e39-f31f-5170-a552-ac33509ffcd6@gmail.com> <<8337o79arh.fsf@gnu.org> <0e2c9c67-12a2-4712-92d2-e3c204f46838@default> <83twgn7hjx.fsf@gnu.org> <83k2hi7lks.fsf@gnu.org> <0b1c64b7-9de7-4d67-bbbb-d1b9a7701af3@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 9300 Cc: andreas.roehler@easy-emacs.de, 9300@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > Date: Tue, 21 Jun 2016 06:31:12 -0700 (PDT) > From: Drew Adams > Cc: 9300@debbugs.gnu.org > > > Yes, the de-facto behavior is actually "at or around point". > > Around only in the sense of something looser than at. > Not around in the sense of before and after. Yes, that's true. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 07:25:13 2022 Received: (at 9300) by debbugs.gnu.org; 28 Apr 2022 11:25:13 +0000 Received: from localhost ([127.0.0.1]:45595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2Gm-0007ZO-RG for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:25:13 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2Gd-0007YT-Ok for 9300@debbugs.gnu.org; Thu, 28 Apr 2022 07:25:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NlFXPy8EKHccvInvPve+jMdw2gOBOJu+HfQi4nZ44Yo=; b=EPTWklsovvYz/u/RLc68Do7/lO ttHxg3tV1STpI+LFxcqa7S4+hnVIuATZEkhseW9rOWR5Nt0l/JJ5jz3rv/taUdVUmH1A3ra3V/uMw 0D5x6GXdRPkdnR21pYm/7H1pVPHb8JRyAug5bqCCr/XscPiFU8WYzNHxGhaEo+xxSjzU=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk2GV-00008b-6h; Thu, 28 Apr 2022 13:24:57 +0200 From: Lars Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING References: <56CBAF58.2000708@yandex.ru> X-Now-Playing: Johnny Boy's _This Is Fascism (1)_: "This Is Fascism (Fascism Mix)" Date: Thu, 28 Apr 2022 13:24:54 +0200 In-Reply-To: <56CBAF58.2000708@yandex.ru> (Dmitry Gutov's message of "Tue, 23 Feb 2016 03:01:12 +0200") Message-ID: <877d79movt.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Dmitry Gutov writes: > I'm not sure it should be fixed. > > Your reasoning seems valid, however by now this behavior is ingrained > into my expectations of how thing-at-point should behave. > > This would be a breaking ch [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 9300 Cc: 9300@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Dmitry Gutov writes: > I'm not sure it should be fixed. > > Your reasoning seems valid, however by now this behavior is ingrained > into my expectations of how thing-at-point should behave. > > This would be a breaking change. For instance, it will make > (bounds-of-thing-at-point 'symbol) unsuitable for use in a > completion-at-point-functions element, to compute the first two values > of the returned list, because during completion you're most often > "after" the symbol. And I do use it for that purpose in one > third-party package. So I think the conclusion here is that we don't want to change the behaviour, and I'm therefore closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 07:25:08 2022 Received: (at control) by debbugs.gnu.org; 28 Apr 2022 11:25:08 +0000 Received: from localhost ([127.0.0.1]:45593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2Gi-0007Z5-Lj for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:25:08 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2Gh-0007Ys-Qe for control@debbugs.gnu.org; Thu, 28 Apr 2022 07:25:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2wtTcokUD07p8JSiJP2BGSf8OYpPCnLVMlNU7FeYebU=; b=rw0kGKwVzcZqtNfFfSWd0yL99C nEXeKOj+kUOWQGIYlQ0lNAmWnhig7NqSNgUdnp4R2gbsrl0j2N/GtLQJvDtvBXSWLjMXRSznH/PY1 gkH39DXRVgtzBNI1S+XrCS7G/ae2qgi9KmzNk8rxoqEXuM4OoLUrZcIrsFa2we/tkss0=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk2Ga-00008i-Ax for control@debbugs.gnu.org; Thu, 28 Apr 2022 13:25:02 +0200 Date: Thu, 28 Apr 2022 13:24:59 +0200 Message-Id: <875ymtmovo.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #9300 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 9300 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 9300 quit From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 11:49:46 2022 Received: (at 9300) by debbugs.gnu.org; 28 Apr 2022 15:49:47 +0000 Received: from localhost ([127.0.0.1]:49674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk6Oo-0005UW-JR for submit@debbugs.gnu.org; Thu, 28 Apr 2022 11:49:46 -0400 Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:47584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk6Ol-0005TV-Sd for 9300@debbugs.gnu.org; Thu, 28 Apr 2022 11:49:45 -0400 Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 23SDh6jp025790; Thu, 28 Apr 2022 15:49:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=F+m1kLr4wCPxwsPuaOUGp6SgyWJWWihXNBeqcIWGP/k=; b=qZi7N/TN/350wE6B7rrqV6rTLLhgyb0SmCIbizg1NGc6jTQu8Mw4Y1j3PjcbZgyxir9m j7YOyAy1kaVKHCVej1LMpvNxCV1l97901l3CJizuZ6KxMIu2yfrBA9p4MHEpjZId4tQQ mMGoxkvEHOL9G7c4JjNt67IQp9CIIWtlSXGQWsVkj8NImCu46WOlrrlc0vF22pk+zgfL P9zzie8/Q2ukrcT4DTwEbY1JkHlwrNG+zd/mAUqnGp0R64mE6SHcL9ixtTypiDNfrEgN 4Dc4jgcteWMBi44YMnngpb5alU51o1ctPN+IKYrEuFeLTtzvD0jI5RiOQ9PuF/hHOhiC 6A== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3fmb1mvj4t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Apr 2022 15:49:42 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 23SFkBfT029708; Thu, 28 Apr 2022 15:49:33 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3fm7w6uku6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Apr 2022 15:49:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ir9wa1gW8Vx5sr95FnZ1WubCy950a9qgV7rw0vxy1ZCvaKEeH3I7jkhrTifrokv4MnhW/zH+KBhfxGdDcLkVY9IhOh+rfnyuT5ZZA8CQfkTTF89gga0GKpJZWH0AFWWRuPuAIvKdJ33MffJ0pY+ou/tnef+NJQmDyiWG8hoWLIRZ73c8w8qUVL40Scgydw7m4rvRf8vJN66SLErZ0n53rp7mLsSqkTsYbMoUozps8ibDSVwdKZamU895nWAwH6qCLXSwblHoKg7ssTBbfjg4bVFp0CwUOudk7/od3l0T6dUVN6QL742NSP2058CWieO4jc0n4qWty3YME2y+1eVpiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=F+m1kLr4wCPxwsPuaOUGp6SgyWJWWihXNBeqcIWGP/k=; b=fy+KECouoRmHeLDzcfu6g1YSyx36pOdZS0TZPCV5rFDoAeHw/ANorN2UVJ5xNCcnzFNHtlxBLAblAoozZFkAB5M2I2H2ZzhjBJRKzl4X5DaOQaFzMUrFIC5aMTq36zrB3/mg6NWcnJO+POCz1WN8SK5OZsB2n8yzekQT4O53qQmEho9PrI6X8jmC5mp4TVy7duwGO6TVlHvrbX4N9GH1tdkkurV55Wo+PPCzryj46FvC+A+qRDAzjFyjYZ+yFvvZbx+fqisPyCltpOQhpdUIm1SLDFiwwalIqr5/gC4cQgruHYC0xhb1F+LoSZNk/JxAWgHW99hJ1XOT1TQc7wfxXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F+m1kLr4wCPxwsPuaOUGp6SgyWJWWihXNBeqcIWGP/k=; b=AB9fpHEsqVP/wUs14DNYzvxXQzFY2lgp2BWfX/RwK48zyaqEvNvMNzm1LYzxyr/Bgs0mY/nx1u/P1TFIuPPMN6e+Bau3/axAunl7UCWqvj+NNgvOv4dSiXeLhQzHnpbzVMwMpDq9gT1Rdtc3Aj8HBYH/+BZerjEcPiSp/qfEheM= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by SJ1PR10MB5906.namprd10.prod.outlook.com (2603:10b6:a03:48b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.21; Thu, 28 Apr 2022 15:49:31 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a0e7:5f38:ab50:5123]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a0e7:5f38:ab50:5123%9]) with mapi id 15.20.5206.013; Thu, 28 Apr 2022 15:49:31 +0000 From: Drew Adams To: Lars Ingebrigtsen , Dmitry Gutov Subject: RE: [External] : Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Thread-Topic: [External] : Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Thread-Index: AQHYWvKcRQLciraHeEyZInAH1hlGZK0FcCfg Date: Thu, 28 Apr 2022 15:49:31 +0000 Message-ID: References: <56CBAF58.2000708@yandex.ru> <877d79movt.fsf@gnus.org> In-Reply-To: <877d79movt.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 746de9d2-b862-44af-ee7e-08da292eaf85 x-ms-traffictypediagnostic: SJ1PR10MB5906:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dPwMu39kewCNxvee1Eg3rfmjePO6OgMagMLzrxvrvcgpkeXph1MWc5oVQhbNcKvgLYvytgvB3VldeDYyuGaZjhqNkekOzcILbR+astwMMoVRXg+AJa0vEciiAWbxl0KtcIbnGnFplVHfq017WaRxbDSu1HEniauYQOikQW1gowZZ6cYD2buVjIS5f+isHt+LgJamJtG4/Pkii2sJKXC1yqhlaqMkMtU7Si+1YRbq2qqNO3Psam3Jv36qG6oDMzRsOJF1/8WDRIGz9bYmENIu7bc2/ky6ksR/sPY+MjXF5+MCn98Vj/h0c7kgbIC1/kHMl/4b9mAg/iAPdfWs0fY0YQlS12a5ecCWw41HAk2ROPIaM6faKr5l17HjgsUq7jf9rLpKa3Z9Ezr1NSv3Fxp2LWpJqZo2U80Cn23hX4uy4XanTACSBLLeY9wKCMi3e8X8/c8SovsM/5LMgdxgZR7pjuO3Xt7/mU60YZSZsG7Oh4LbXfKsH+Lt14PTJjhvREshbFqPaKTcOeNOSP07EeKBCJI2U9cFOoxsIZuBiPniIilOpxTzrYQRoxPVRCK8NN3fw3Q30SRRS0ToxLQK1iUnZCjaI/+lEBi4NRHDkgvenN1Jd+iZf7CVVjZaJ8SacPRpdBvJUP7TjrKe0WHxRZpoRteeJ00k0QOpb+kEi5bOnRjB0jYzLBoqARIunwUi88zV/l3uR1lxs+zLDK49jYllcKyW+zIFAm8E+/4alLLbYUs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(33656002)(2906002)(7696005)(8936002)(26005)(6506007)(86362001)(508600001)(186003)(44832011)(9686003)(316002)(5660300002)(122000001)(38070700005)(38100700002)(52536014)(4326008)(110136005)(66446008)(66476007)(66556008)(66946007)(8676002)(55016003)(64756008)(71200400001)(76116006)(81973001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+n0Ht6+p2pOvPsSg/53KMxoK345/IntR4SujyLPJ9aN26CnH0HiyzdJbNYta?= =?us-ascii?Q?0Yy+Ts/DWOKSla+NFcfRotgtpBcIMjefuUN0fC65mtdBTN0Dp7FcC6LkXHeL?= =?us-ascii?Q?7sLanKlRTg7GuR0cj4cfIL91wiWNdoQwkdJ2/cAcKD1qVPq6xRYqy8Kv7934?= =?us-ascii?Q?kpYTA+hMsOQgI0NCPb5q9OIfWpNuPxAYprmO/hZLyeglvE6G47X0MgcefYa6?= =?us-ascii?Q?v7QHXvvyl6T5goHZCUP5pbJ0GfGKdPncvsOhRLXZewxHWhmMIPjHkYusba+0?= =?us-ascii?Q?nepU6TWHfQIvOlJEDHC5lTn4YGbmueaqPa2nsd0whpJhfXy4XIzJMmjTiEdu?= =?us-ascii?Q?tSnWRQDvWuO/jbztKpHu6nL17/XxuGpQm30uFsqW3ITYL9ANWj+xE5glhChl?= =?us-ascii?Q?0F5tPT0HrhvGJRXr11W+VaVONGmiBqTZ7H9ZofBBeo7Epaj/yRi3CjjQRe0x?= =?us-ascii?Q?Tz00ZeeINyoCEyJwnoUfN6FauaRK0qRYrlSn7EIegrlXp/RQlAypco89aPNf?= =?us-ascii?Q?vKnOlt6v/2Sw/t7qcBP0rOLiL2bEVdoCNvAhvMsEi1bom9NFUK3ZTsvBFrlB?= =?us-ascii?Q?tt+5TrCQoZBp89CTPvpZR/Ksyu6FROhVguzgdnHYqEnFTIZmW6GRygw3aFfA?= =?us-ascii?Q?QBk2wixxQ2Zz/GbXrUKRwVOzz2gzQgEiwR1/by6pyA6lj+qrPWTRCYhZk0EX?= =?us-ascii?Q?7idt3qmaYn+9GIrUz4y4iSuVGBjPCSz+fvzIo5sAnWTHLNDS0Ej+owiPmdc7?= =?us-ascii?Q?xNfCChMjRfbS+F9NDIbOPXn63WTGFh5BGlNIXheXlAqgt7RQwL5gC+B1iyeC?= =?us-ascii?Q?VPmSqk/T0scfEGhCrFfqArN2huD6MuCgcjfrrm9RRKEAhgluEUBletGPBjM/?= =?us-ascii?Q?O/NdPMKNbU8ernXMxvcjf6jm+HeESSjXQxg9pgoRWyb7sW2Od4j/Q0bC0beb?= =?us-ascii?Q?EdaZgoYUSfVn2w9l6S2AMOfzT+psGwvibdwg/hpb3YZCt5vuuk9lpoFRx0WN?= =?us-ascii?Q?/a4qi+sPUCjCPDhn4GxfCm7NdUmZdaO0zRVUyzmsvjhmvI7yEtJz2xKj1CvE?= =?us-ascii?Q?K/4e1rOVnGscPYD0Lq8PNnGPTr42ISZ0Q++d2zg1m1cIfU4oLwtnv9HmPwBg?= =?us-ascii?Q?OxIZuqCZ3EmDbLFW8XyjftA1GqWqN7qtLyp4JfpAec/ae/hBAjxKGnYg7Hzn?= =?us-ascii?Q?F+94P5qIikcVsWWvmfi24bpmsiz4CAM0+vB5FNlO03TiYBYXvOjdJyFLtBt7?= =?us-ascii?Q?EgxhhJmnV2XlDgduluZnjZ5ahYbuMCPW8TK/VueG3rCuivlCybrihc7Lj17c?= =?us-ascii?Q?QHxTJhNN7BcpG/O7YrXkftpu/X2AAGG4EpxnUaxdQ3b+qxFafXqnPLIVauLm?= =?us-ascii?Q?wAd2Oan8jitVRBlXHVnMN0K+IMZ5YQX/79EM7eGBCaWdMwJIzCsxAKPPa12a?= =?us-ascii?Q?tpvRbbXrxDU7WkMA+vXcHKPBFpvsuPAo8kXnWVWKZ34orYlWngJEuC2T2A4w?= =?us-ascii?Q?w6xB+CFUhaUWWyE/mBEbiYVQT3tA7/b7RUBSCvVY4gl23VfQ4xR4IiKwBnzU?= =?us-ascii?Q?Z6WyvV5QM6YdQHLgsqEUAkpiLQ9PHP6pk0CjfT08SKKVDnmNGBAfVlCNy8aw?= =?us-ascii?Q?PRJQtkeSpJlPcy2VQEak/FfVppJ7zBUybEM3VixW9z7wwAiC4EbA+rWZfI2d?= =?us-ascii?Q?9Rl7jualcMJGfVMLTUFRGgvkyYlNfV924MIKLHJuj7apLdaPKp71QKvt2eKL?= =?us-ascii?Q?9TuTrXMWQw=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 746de9d2-b862-44af-ee7e-08da292eaf85 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2022 15:49:31.6214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JvYhExLJbCm99Rz1kqneKVG8xkB6SQFBajk78G+10wBG7aMu5aCV2JPaoqCpQ0F/P3L/lesAo2F96S+MB0UdxA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR10MB5906 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-04-28_02:2022-04-28, 2022-04-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=855 malwarescore=0 mlxscore=0 phishscore=0 bulkscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204280094 X-Proofpoint-GUID: ja5z-iagE06wCSuP4U5q9IJ_bEys8Zdt X-Proofpoint-ORIG-GUID: ja5z-iagE06wCSuP4U5q9IJ_bEys8Zdt X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 9300 Cc: "9300@debbugs.gnu.org" <9300@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > So I think the conclusion here is that we don't want to change the > behaviour, and I'm therefore closing this bug report. This is extremely unfortunate. Quite misguided. This completely misunderstands and misses the point of `thingatpt.el' - in particular of `bounds-of-thing-at-point'. The point is NOT simply to try to obtain a thing (and its bounds) _near_ point. The aims and use cases (there are two) are: 1. To find out _whether there is_, in fact, a THING at point. AT POINT - not point OR (point - 1). 2. IF there really is a THING at point, to return it (or its bounds). This bug is about the misguided behavior that returns the THING at (point - 1) instead of returning nil, when there's NO THING at point. This bug renders thingatpt.el useless for any functionality that needs to know _whether_ there's a THING at point. And that means a loss of lots of use cases - down the drain. The miscoding is motivated by an expectation that the only thing anyone ever wants to use thingatpt.el for is to get a THING near point for use as a default value for reading input. That's the least useful application of thing at point. (It's a common one, admittedly.) ___ It's possible to define other functions that do have as their only aim to return a THING that's NEAR point. As mentioned in the bug thread, it's not hard to do that , and even to let callers specify a tolerance that defines NEAR. Such a function is really what should be used to get some default text for reading minibuffer input. (I've offered this - code.) But a get-some-THING-near-point functionality doesn't in any way _replace_ the need for aims 1 and 2 of the thingatpt.el design. The code is corrupted, resulting in loss of the raison d'etre for thingatpt.el. A new low for Emacs. From unknown Wed Jun 25 10:52:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 27 May 2022 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator