From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Date: Wed, 24 Feb 2016 02:52:36 +0200 Message-ID: <27990eb0-3d4e-62c7-257d-7ea7a8204e2d@yandex.ru> References: < <56CBAF58.2000708@yandex.ru> <3a64315c-fc72-42bd-a6cf-0fa43414daa6@default> <56CC32CD.5050906@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1456275244 6161 80.91.229.3 (24 Feb 2016 00:54:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Feb 2016 00:54:04 +0000 (UTC) To: Drew Adams , 9300@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 24 01:53:51 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aYNiB-0000Wq-LU for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Feb 2016 01:53:51 +0100 Original-Received: from localhost ([::1]:60841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYNiB-0000XF-46 for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Feb 2016 19:53:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYNhS-00081W-6v for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 19:53:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYNhO-0005ew-6M for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 19:53:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYNhO-0005es-3D for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 19:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aYNhN-0000rU-Tz for bug-gnu-emacs@gnu.org; Tue, 23 Feb 2016 19:53:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Feb 2016 00:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9300 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9300-submit@debbugs.gnu.org id=B9300.14562751673293 (code B ref 9300); Wed, 24 Feb 2016 00:53:01 +0000 Original-Received: (at 9300) by debbugs.gnu.org; 24 Feb 2016 00:52:47 +0000 Original-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 Original-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 Original-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) Original-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) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113621 Archived-At: 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.