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 09:58:12 -0800 (PST) Message-ID: 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> 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 1478714364 31758 195.159.176.226 (9 Nov 2016 17:59:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Nov 2016 17:59:24 +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 Wed Nov 09 18:59:20 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 1c4X9S-0006Sk-D3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Nov 2016 18:59:10 +0100 Original-Received: from localhost ([::1]:41605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4X9V-0002PQ-Hk for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Nov 2016 12:59:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4X9P-0002P4-4p for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 12:59:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4X9K-0007ep-9O for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 12:59:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4X9K-0007ek-6J for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 12:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c4X9J-0006ue-TC for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 12:59: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: Wed, 09 Nov 2016 17:59: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.147871430426532 (code B ref 21391); Wed, 09 Nov 2016 17:59:01 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 9 Nov 2016 17:58:24 +0000 Original-Received: from localhost ([127.0.0.1]:51187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4X8i-0006ts-In for submit@debbugs.gnu.org; Wed, 09 Nov 2016 12:58:24 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:19688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4X8g-0006tf-Qi for 21391@debbugs.gnu.org; Wed, 09 Nov 2016 12:58:23 -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 uA9HwGAr013100 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2016 17:58:16 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id uA9HwDnC026320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2016 17:58:15 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uA9HwD8k005439; Wed, 9 Nov 2016 17:58:13 GMT In-Reply-To: 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:125525 Archived-At: > If we agree that the return value of thing-at-point should be a > string, (get 'number 'thing-at-point) can't return `number-at-point', it > should return a function that will return the said number as a string. Oh, God, no. That would be among the most misguided proposals I've heard in a long time. That truly throws out the baby with the bathwater. It is not property `thing-at-point' that should return (a function that returns) a string; it is function `thing-at-point' that should return a string - if anything should. > And of all things enumerated in thing-at-point's docstring, That list is only an indication of some of what is possible. > IIUC only number has such problem.=20 It has no problem that I'm aware of. What's the problem? `number-at-point' returns a number, as it should. `list-at-point' returns a list, as it should, and so on. (get 'number 'thing-at-point) returns `number-at-point', which is 100% reasonable. > Which leaves third-party things, but, they will either need > to be fixed, I get the impression that your idea of what is broken and needs to be fixed is very different from mine. > or people will have to remain content not to use thing-at-point > with NO-PROPERTIES argument on them. What is "them"? What Eli has suggested is one reasonable approach: just prevent raising the stupid error. I proposed at least two other reasonable approaches. In none of those suggestions is there a problem with calling `thing-at-point' on ANY kind of THING while using non-nil NO-PROPERTIES. It is not clear what you are seeing as a problem, for which you think that requiring or prescribing that property `thing-at-point' return a (function that returns a) string is the solution. > I can't imagine that loophole to be too useful. The proposal above > should leave all such uses of third-party things alone. But yes, > anyone who uses (thing-at-point 'number) as a (longer, pointless) > substitute for (number-at-point) will have to change their code. 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. 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 > To make thing-at-point behavior more consistent. This kind of thing > is usually performed with future new uses in mind. But it also might > help with code maintenance a bit, for existing users (not likely to make > much of a difference, but still; the danger of breakage is not very > significant either). I really disagree with what seems to be your view of thingatpt.el functionality. 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).