From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams 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: Wed, 6 Jul 2016 23:31:25 +0000 (UTC) Message-ID: 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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1467847954 4507 80.91.229.3 (6 Jul 2016 23:32:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2016 23:32:34 +0000 (UTC) To: Dmitry Gutov , =?utf-8?B?QW5kcmVhcyBSw7ZobGVy?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 07 01:32:18 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 1bKwIi-00059a-Ia for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 01:32:16 +0200 Original-Received: from localhost ([::1]:36342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKwIe-0006Or-GY for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2016 19:32:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKwI5-0006Om-TD for emacs-devel@gnu.org; Wed, 06 Jul 2016 19:31:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKwI2-0006sd-LW for emacs-devel@gnu.org; Wed, 06 Jul 2016 19:31:37 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:35346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKwI2-0006s9-C8 for emacs-devel@gnu.org; Wed, 06 Jul 2016 19:31:34 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u66NVTQr025091 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Jul 2016 23:31:29 GMT Original-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 u66NVSDI021573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2016 23:31:28 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u66NVPMV024320; Wed, 6 Jul 2016 23:31:26 GMT In-Reply-To: <4a8dc209-e526-24b4-ac63-de5c32bfed2c@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:205292 Archived-At: > > 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. >=20 > completion-at-point is the same as thing-at-point in this regard, current= ly. (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.