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: Wed, 9 Nov 2016 16:40:09 -0800 (PST) Message-ID: <8c2b4b8b-0e49-42af-a98d-d82006f90354@default> References: <0a68c2ae-0940-4e2c-8b3c-1faceb45c43c@default> <1773ab35-70b1-42f9-8a8b-fe07881487d1@default> <874m3krnb6.fsf_-_@gmail.com> <83a8dbiaps.fsf@gnu.org> <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> <1c17de6b-2297-6e7e-9b06-e84b5b6df3eb@yandex.ru> 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 1478738492 17583 195.159.176.226 (10 Nov 2016 00:41:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Nov 2016 00:41:32 +0000 (UTC) Cc: tino.calancha@gmail.com, 21391@debbugs.gnu.org To: Dmitry Gutov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 10 01:41:28 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 1c4dQU-0001mZ-I1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Nov 2016 01:41:10 +0100 Original-Received: from localhost ([::1]:43167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4dQX-0004LR-J7 for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Nov 2016 19:41:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4dQR-0004LA-DJ for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 19:41:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4dQM-0007cg-7G for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 19:41:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36082) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4dQM-0007cY-2f for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 19:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c4dQL-0001PL-SN for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 19:41: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: Thu, 10 Nov 2016 00:41: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.14787384205351 (code B ref 21391); Thu, 10 Nov 2016 00:41:01 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 10 Nov 2016 00:40:20 +0000 Original-Received: from localhost ([127.0.0.1]:51481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4dPg-0001OF-JZ for submit@debbugs.gnu.org; Wed, 09 Nov 2016 19:40:20 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:21361) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4dPe-0001O2-Mz for 21391@debbugs.gnu.org; Wed, 09 Nov 2016 19:40:19 -0500 Original-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 uAA0eB51010969 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2016 00:40:12 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id uAA0eBH2011162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2016 00:40:11 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uAA0eALf024896; Thu, 10 Nov 2016 00:40:10 GMT In-Reply-To: <1c17de6b-2297-6e7e-9b06-e84b5b6df3eb@yandex.ru> 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: aserv0021.oracle.com [141.146.126.233] 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:125540 Archived-At: > > (get 'number 'thing-at-point) returns `number-at-point', which > > is 100% reasonable. >=20 > Not at all. As I've explained previously. No, you have not. This is the whole point of symbol property `thing-at-point', and it always has been. What do YOU think is the point of putting property `thing-at-point' on a THING type? > > Not wanting someone to use (thing-at-point 'number) to return > > a number via (get 'number 'thing-at-point) is one thing. > > And it is already addressed by what I proposed. >=20 > I must have missed that proposal. I showed three possibilities, and I pointed out which one I prefer. The bug thread is there, in case you really missed it. > > Not wanting to let (get 'number 'thing-at-point) to return a > > function that returns a number is quite another thing altogether. > > And it is totally uncalled for. >=20 > Isn't that one and the same? Of course not. The use of (get 'number 'thing-at-point) in the definition of `thing-at-point' is only _one_ use of it. That's apparently what you've missed from the beginning: the point of symbol property `thing-at-point'. You will see things like this in thingatpt.el: (put 'url 'thing-at-point 'thing-at-point-url-at-point) (put 'email 'thing-at-point (lambda () (let ((boundary-pair (bounds-of-thing-at-point 'email))) (if boundary-pair (buffer-substring-no-properties (car boundary-pair) (cdr boundary-pair)))))) (put 'number 'thing-at-point 'number-at-point) And that's only a few predefined uses of it. One of the main points of the library is to provide tools that you can use to define your functions that implement providing a THING at point. And by that I do not mean just a string at point that names a thing - I mean a Lisp THING (list, sexp, number, color name, file name,... whatever). It is irrelevant to the design of thingatpt.el, and its intended use cases, that the THINGs defined for `url' and `email' are string values. They are no more "normal" cases for the design than is `number'. What is important is that the design provides this functionality for _any_ kind of THING - any Lisp value. Examples of other THING-returning definitions: (put 'list 'thing-at-point 'my-list-at-point) (put 'unquoted-list 'thing-at-point 'my-unquoted-list-at-point) (put 'non-nil-symbol-name 'thing-at-point 'my-non-nil-symbol-name-at-point) (put 'symbol-name 'thing-at-point 'my-symbol-name-at-point) (put 'region-or-word 'thing-at-point 'my-region-or-word-at-point) (put 'color 'thing-at-point 'my-color-at-point) (put 'decimal-number 'thing-at-point 'my-number-at-point-decimal) (put 'hex-number 'thing-at-point 'my-number-at-point-hex) (put 'string 'thing-at-point 'my-string-at-point) Some of those THING types are strings; some are lists; some are symbols; some are numbers. The THING possibilities are limitless. Practically the entire design of thingatpt.el revolves around putting properties on THING-type symbols and function symbols. This includes property `thing-at-point'. > > I disagreed with it strongly in the context of bug #9300, where > > you were the lone voice proclaiming it. You apparently view the only > > use of this functionality as returning a string near (not at) > > point that can be used as an input default value. thingatpt.el is much > > more than that. It is very important that it be able to be used > > to test whether there (really) is a given THING _at_ point (not > > just somewhere near point). >=20 > That seems orthogonal to the current discussion. It points to the fact that you apparently have only a limited view of what thingatpt.el is for and what features it provides. You've missed two for two, so far - and important ones, at that.