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: Tue, 8 Nov 2016 08:31:00 -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 1478622777 12091 195.159.176.226 (8 Nov 2016 16:32:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 8 Nov 2016 16:32:57 +0000 (UTC) Cc: tino.calancha@gmail.com, 21391@debbugs.gnu.org To: Eli Zaretskii , Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 08 17:32: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 1c49Jg-0006Nr-SR for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Nov 2016 17:32:09 +0100 Original-Received: from localhost ([::1]:34117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c49Jj-0002eK-VD for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Nov 2016 11:32:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c49Jd-0002eF-TU for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 11:32:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c49Ja-0005oL-Pv for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 11:32:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34447) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c49Ja-0005oH-MM for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 11:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c49Ja-00040p-Ge for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 11:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Nov 2016 16:32:02 +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.147862267215340 (code B ref 21391); Tue, 08 Nov 2016 16:32:02 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 8 Nov 2016 16:31:12 +0000 Original-Received: from localhost ([127.0.0.1]:49842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c49Im-0003zL-5Z for submit@debbugs.gnu.org; Tue, 08 Nov 2016 11:31:12 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c49Ik-0003z6-TI for 21391@debbugs.gnu.org; Tue, 08 Nov 2016 11:31:11 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA8GV4tk031544 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Nov 2016 16:31:04 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id uA8GV38N025936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2016 16:31:04 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uA8GV1is014152; Tue, 8 Nov 2016 16:31:02 GMT In-Reply-To: <<83inrygggr.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: aserv0022.oracle.com [141.146.126.234] 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:125472 Archived-At: > I'm not sure what issue we are discussing and what problem we are > trying to solve. Let me take a step back and describe the situation > as I see it. >=20 > This bug report started because thing-at-point would signal an error > for some of its calls. That bug is already fixed. Tino was unhappy > with using sequencep and wanted to replace that with stringp -- fine > with me, I don't object to such a change. >=20 > From my POV the issue should be closed once we agree on the > predicate > to use when deciding whether or not stripping the text properties is > appropriate. >=20 > But then somehow the discussion shifted to be about whether to > _force_ thing-at-point value to be a string, even if it isn't > for some reason. > > I don't understand the rationale for such a change. Yes, > thing-at-point was most probably always meant to return a string. > Yes, Lisp code that causes it to return some other object is > probably wrong. However, the change that allowed this was > introduced 19 years ago; who knows what code out there actually > uses this loophole? If there is such code, why would we want to > break it? To what end? And if no code uses this loophole, why > do we care that it exists? >=20 > IOW, thing-at-point no longer has any known bugs, and we are talking > about forcibly breaking a use case that does no harm to us, and can > only happen if someone abuses the 'thing-at-point' property, which > would make it that someone's bug/misfeature, for them to fix. >=20 > So why would we want to make such a change? What am I missing? FWIW, I agree with you here, in general. (I do not agree that thingatpt no longer has any known bugs, however. See bug #9300, which is a very important bug, to me.) On the other hand, I'm pretty sure that some Emacs Dev deciders have previously proclaimed that it is wrong for someone to exploit this "loophole" and thus have `t-a-p' return something other than a string. And, as Tino points out, the doc says clearly that it returns a string - no ifs, ands, or buts about that. So yes, enforcing returning a string would be an incompatible change. But it would (apparently) do what Emacs Dev has said the function should do, and it would do what the doc says it does ((elisp) `Buffer Contents'). Yes, deciding to enforce returning a string is outside the error that was reported in this bug report. On the other hand, the bug title is precisely, explicitly this question we are discussing now: Should `t-a-p' return a string? I can work with this either way. Long ago, I adapted my own code to fit the prescription that `t-a-p' must return a string. But I guess I could make an incompatible change to my code, to once again realign it with allowing a non-string return value. My preference, at least so far, would be for us to do the following: 1. Enforce a string return value, in the way suggested. 2. CLEARLY point out, in the high-level doc, that returning a THING at point can mean two different things: * For `thing-at-point' it means return text (a string) that names/represents a THING. * For `form-at-point' and its callers (e.g., `symbol-at-point', `list-at-point', `sexp-at-point', `number-at-point'), it means return a THING, not its name. That is, it returns an Emacs-Lisp entity - any kind of value that Lisp can return. If we do NOT go down this road, but we instead stick with what is there now (i.e., we do not enforce a string value for `t-a-p') then I think it is imperative that we point out, in the doc, that `t-a-p', like `form-at-point' and its callers, can return a Lisp THING of any kind OR a string naming such a THING, and that the former case is realized via property `thing-at-point' on the THING-argument symbol. Being clear and explicit about what it does and how will help avoid the kinds of ambiguity that have plagued this function for a long time now.