From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Newsgroups: gmane.emacs.devel Subject: Re: Fwd: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Date: Thu, 7 Jul 2016 10:00:22 +0200 Message-ID: <9f3302b8-4e81-0ba4-8823-7d101ab73ce2@easy-emacs.de> References: <83k2hi7lks.fsf@gnu.org> <310f04c8-c2e0-a38e-4f31-1955c1eff7a4@easy-emacs.de> <4a8dc209-e526-24b4-ac63-de5c32bfed2c@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1467878160 780 80.91.229.3 (7 Jul 2016 07:56:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2016 07:56:00 +0000 (UTC) Cc: John Wiegley , Drew Adams , Dmitry Gutov To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 07 09:55:53 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bL4A3-0007ap-B2 for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 09:55:51 +0200 Original-Received: from localhost ([::1]:38096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL49z-0002WC-Hr for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 03:55:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL49s-0002Pq-Ed for emacs-devel@gnu.org; Thu, 07 Jul 2016 03:55:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bL49n-0001ma-EO for emacs-devel@gnu.org; Thu, 07 Jul 2016 03:55:39 -0400 Original-Received: from mout.kundenserver.de ([212.227.17.10]:60901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL49m-0001mL-V7; Thu, 07 Jul 2016 03:55:35 -0400 Original-Received: from [192.168.178.35] ([77.3.41.29]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0LlVlX-1bt1ra3FYd-00bGyh; Thu, 07 Jul 2016 09:55:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 In-Reply-To: X-Provags-ID: V03:K0:drLleKaagFANGlVR8nksiyRbn13O1DM3DWMx9RWmXV14mn4WUfi nRwPeRi5JqzrYGV6kFAE+lBwAUK8ByjDEcvYxWn5JD2eEy1ytHD8Cutk0fgT2nRyEGSDxZh cUYMYZJlClJvljpAE/CcvJ2KlQMvfttch3lJcIcCSRPb2T59ee9vdjt1Eil1JNYMj0yzJwA kNlth7sL0AJwoicGmJQHg== X-UI-Out-Filterresults: notjunk:1;V01:K0:gV8Qhaqt9ac=:8UOHWnPDn1Un9gbrlhMl8M asEDFLo7kP7isg8FlInAR0/bOfzXyZaMj57SdqRUG3a0PI4uGOn5vIY13OOuRvKiuxwlstxsl TKdJPiorKU5CXHXK5XhYyof+TV4wa/vQSaOqcfAomzJVA3QEEN3xsRz+soDRRt8hKixpp64Bi iFylCAmMoPezkHpVA6X1DpqlofbcrBAj2AAyfObI3/GCZDGHmIdsNaSAO9+P8GMlYwdCyl82B vU8nqkmYFXySCWqy/hSdafLv+zWQGp1/CSZzrFGUB1XTc/oBgyXGBwyXrYgP1UDN0GjVVNTgs dGv5WFhxm6OJ5utbwVGa1gyyCZ6+y/zSQ5X7ILyyO4sZmZc73irBSEDEnccqGAzn3V7eTk2ne UDk7YG4yojxLZbuL+115xhle4YFELD6IyF8mGmspjt/quqM07G6zpLw4UjE7s9hIuVfGXiCST +9EiE9MzJr8GLAovupPCvgEZ/Wew42/0sBeXk4GbMt38vDsOaaNJCKBmQqo8o4JuqrAbpISzz 9aw0Z0KJm5AOtif7DVZCgjGpYtSvzRgvbgGnZVPCkH7wfN6dtMGhNGotDG5M03MjX20nNdMQv zcenj4O4JsQz8KIXzaNaj/lEAr9wSvp5RuW6R5iqpj1tzskCsWS2eJNWaR6b1IOTqLRDIbvgt byBF7VLCGwUSR47Ez3vs5CY8vGipROcyrbcP9zqcsT3QWrpXr+WbyZKElzyBa8m6BMwdDC6nr NmS7/bNRBWnyBHxK X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205304 Archived-At: On 07.07.2016 01:31, Drew Adams wrote: >>> The first thing I'd like to ask is whether the suffix "-at-point" means >>> the same thing everywhere it appears. If `bounds-of-thing-at-point' is the >>> only place where it differs, it's worth thinking about. >> completion-at-point is the same as thing-at-point in this regard, currently. > (Of course it is. All completion defaulting cares about is getting > something _near_ point, not determining _whether there is_ something > at point, and if there is, getting that. It doesn't care to be precise > about what's _at_ point. On the contrary; it wants to maximize getting > something near point.) > > The _character_ "at" point (which is what this comes down to) is not > usually how we talk about this. Point, like any other buffer position, > is always _between_ chars (or is at bob or eob). We have functions > such as `char-after' and `char-before'. So the more precise way of > talking about this is the character after (i.e., just after) point. > > But the point (!) of the thing-at-point functions is to pick up a > thing that is really "at" some position. And the point of the bug > report is that a position means a _single_ position. > > In order to be precise, and thus to be generally usable, including in > a repetitive way, progressing through a buffer etc., the thing-at-point > functions need to refer to a single position - whether that be chosen > by convention to be the position just before the character in question > or the position just after it. > > See the opening salvos of the bug report for a discussion of why > thing-at-point really means thing just after point. I don't want > to repeat everything here (dunno why this was moved out of the bug > thread, either). > > The point (!) of the bug report is that the thing-at-point feature > cannot reasonably mean just give me EITHER a thing before point OR > a thing after point (even if it gives you the first of those that > it finds). > > That would be OK if all you expect of the functions is to grab > something _near_ point in the buffer, to use as a default value > (e.g. for completion or input). It is not OK when it comes to > really making use of the functions in a precise way, and in > particular, a repetitive way, to progressively deal with things > through a buffer. > > What's needed for a real thing-at-point is what the (simple) bug > fix provides: unambiguously provide the thing just after point - > only. More generally, the functions need to return a thing at > some ONE position, however that position is decided on. And they > need to return nil when there is no thing at that position. > > On the other hand, what's needed (it would be an improvement) for > the more loose uses of thing-at-point, such as getting a default > value, is thing-NEAR-point functions. And the bug report points > to exactly such (existing) functions, even with user or code > control over how near "near" is, horizontally and vertically. > > That kind of function is appropriate in contexts where all you > care about is _getting something near point_, and you in fact > want to maximize the ability to getsomething and you don't need > to determine _whether or not_ there really is a thing at a given > position. > > In sum, both are useful: > > * Functions that deal with a thing AT a given position, precisely. > * Functions that deal with a thing NEAR a given position. > > Both are addressed in the bug thread. But the purpose of the bug > report is to get the former fixed so it DTRT: returns a thing at > the char just after point, or returns nil if there is none such. +1 (defun foo())(defun bar()) (length "(defun foo())") => 13 The opening paren of "bar" is at pos 14. I.e. at-point 14 belongs the definition of bar. However, when copying "foo", it needs (buffer-substring-no-properties 1 14) => "(defun foo())" Think of at-point as of visibility of cursor in buffer.