From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21391: 24.5; `thing-at-point' should return a string Date: Mon, 14 Nov 2016 09:33:00 -0800 (PST) Message-ID: References: <<>> <<<83pom7gjhl.fsf@gnu.org>>> <<<0a8d76e4-4d1b-a26d-2b76-a2d9384d9f72@yandex.ru>>> <<<83mvhbgitf.fsf@gnu.org>>> <<<25bb22e8-1388-275a-d0da-7e698acdf6da@yandex.ru>>> <<<83inrygggr.fsf@gnu.org>>> <<>> <<<83y40sfyij.fsf@gnu.org>>> <<<76505436-e66c-0ed3-6d7a-ce654f38ef30@yandex.ru>>> <<<83bmxnfhbi.fsf@gnu.org>>> <<<73600483-1df5-597c-6066-232189bbdd4a@yandex.ru>>> <<<834m3ffeb9.fsf@gnu.org>>> <<>> <<<83twbfdvav.fsf@gnu.org>>> <<<73be4b9d-2df8-cc83-b873-398cb7dd043b@yandex.ru>>> <<<83pom3ds3e.fsf@gnu.org>>> <<>> <<>> <<<83bmxme12w.fsf@gnu.org>>> <<>> <<<834m3edqyr.fsf@gnu.org>>> <<<6dbea00c-3bde-6ec3-b109-7aa205bedb5f@yandex.ru>>> <<<8337iydq8z.fsf@gnu.org>>> <<>> <<<83y40qc9jv.fsf@gnu.org>>> <<>> <<>> <<<83a8d2hy8f.fsf@gnu.org>>> <<5a6ddd21-ebf9-42bf-9fb6-7fc9e037b3ed@default>> <<83zil2ggf7.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1479144897 30262 195.159.176.226 (14 Nov 2016 17:34:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2016 17:34:57 +0000 (UTC) Cc: tino.calancha@gmail.com, dgutov@yandex.ru, 21391@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 14 18:34:52 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6L97-0002lx-UC for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2016 18:34:18 +0100 Original-Received: from localhost ([::1]:41777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6L96-0002E1-0J for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2016 12:34:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6L8v-0002Cw-Mq for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 12:34:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6L8s-00071W-EU for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 12:34:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41918) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c6L8s-00071Q-B5 for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 12:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c6L8r-0007ZA-Uh for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 12:34:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Nov 2016 17:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21391 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21391-submit@debbugs.gnu.org id=B21391.147914479329021 (code B ref 21391); Mon, 14 Nov 2016 17:34:01 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 14 Nov 2016 17:33:13 +0000 Original-Received: from localhost ([127.0.0.1]:57317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6L84-0007Y1-Qs for submit@debbugs.gnu.org; Mon, 14 Nov 2016 12:33:13 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:25724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6L82-0007Xm-PA for 21391@debbugs.gnu.org; Mon, 14 Nov 2016 12:33:11 -0500 Original-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 uAEHX4m0027509 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Nov 2016 17:33:04 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id uAEHX2WM002274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Nov 2016 17:33:02 GMT Original-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 uAEHX1pf031484; Mon, 14 Nov 2016 17:33:02 GMT In-Reply-To: <<83zil2ggf7.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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" Xref: news.gmane.org gmane.emacs.bugs:125695 Archived-At: > > > > d> 2. Make `thing-at-point', as before, return just what the > > > > firat `if' clause returns, if that clause is taken. > > > > IOW, move the removal of text properties (from non-nil > > > > NO-PROPERTIES) into the second `if' clause. > > > > > > Why would we want to do that? AFAIU, it would require the > > > function that is the value of the thing-at-point property to > > > second-guess what the caller of thing-at-point wants, something > > > it has no means to do. > > > > Quite the contrary. It gives the function that is the value of > > the property the ability to determine the return value. Which > > is precisely the intended behavior of that property, from the > > start. >=20 > So you are saying that the function should control the caller, > instead of the other way around? That makes very little sense to me, > because the function writer has no way of knowing the caller's intent. If the THING has property `thing-at-point' then the function that is the value of that property controls the behavior of function `thing-at-point' _for that type of THING_. Yes. That is the design. And of course you can override the behavior locally or temporarily by removing the symbol property (and then restoring it). You can, similarly, change the symbol property, to locally or temporarily get different behavior. I don't see that being done often. I've never seen it done, in practice - but it could be done. All this just means that what you call the "caller", function `thing-at-point', does not have its behavior decided/defined once and for all, ahead of time. Its behavior is controlled by the symbol property, in addition to the `thing-at-point' defun. Again, this is very similar (it is equivalent) to what happens when you pass a function-valued parameter to a higher-order function. In effect, `thing-at-point' is a higher-order function, because of symbol-property `thing-at-point'. Being able to put the property on specific THING symbols is a way of making the higher-order nature more specific (THING type-specific). And (except for the fact that the property value could be changed at runtime) this differs from passing a function-valued parameter that is computed at runtime: with this design, the THING-specific behavior is defined at coding time, not at runtime. A user or a 3rd-party library can easily define a specialized (including a personally preferred) behavior for a given THING type, simply by setting property `thing-at-point'. No advising needed. (You can think of it as a kind of hook, if you like.)