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, 7 Nov 2016 08:10:34 -0800 (PST) Message-ID: <123efdfd-3a87-4b39-9567-a56ecc3ea82e@default> References: < <0a68c2ae-0940-4e2c-8b3c-1faceb45c43c@default> <1773ab35-70b1-42f9-8a8b-fe07881487d1@default>> <<874m3krnb6.fsf_-_@gmail.com>> <<83a8dbiaps.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 1478535389 1590 195.159.176.226 (7 Nov 2016 16:16:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 Nov 2016 16:16:29 +0000 (UTC) Cc: 21391@debbugs.gnu.org To: Eli Zaretskii , Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 07 17:16:25 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 1c3maQ-0004kz-8U for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Nov 2016 17:15:54 +0100 Original-Received: from localhost ([::1]:55000 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3maT-0001rK-88 for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Nov 2016 11:15:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3mVo-0006PL-9b for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2016 11:11:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3mVi-0006Qt-5B for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2016 11:11:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33168) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c3mVi-0006QT-2V for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2016 11:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c3mVh-0006o6-P3 for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2016 11:11: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, 07 Nov 2016 16:11: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.147853505126150 (code B ref 21391); Mon, 07 Nov 2016 16:11:01 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 7 Nov 2016 16:10:51 +0000 Original-Received: from localhost ([127.0.0.1]:48567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3mVX-0006ni-1k for submit@debbugs.gnu.org; Mon, 07 Nov 2016 11:10:51 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26799) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3mVV-0006nW-BL for 21391@debbugs.gnu.org; Mon, 07 Nov 2016 11:10:49 -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 uA7GAgol026962 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2016 16:10:43 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id uA7GAgZ1009383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2016 16:10:42 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id uA7GAaD6005193; Mon, 7 Nov 2016 16:10:37 GMT In-Reply-To: <<83a8dbiaps.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: 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:125424 Archived-At: > > > A proper fix is to convert the result returned by > > > (funcall (get thing 'thing-at-point)) to a string. > > > For that, you can use (format "%s" thing). > > > > It's natural if `thing-at-point' returns the thing as a string. > > When the user don't want a string then s?he can use the specific > > functions, like `number-at-point' or `list-at-point'. >=20 > Isn't that completely backward-incompatible? If so, I don't think > we can do that. >=20 > I don't really see what is "improper" with the other suggestions to > fix this bug, which simply avoid signaling an error if the "thing at > point" happens to be something other than a string? `thing-at-point' has always allowed, and rightfully so, its default behavior to be replaced by putting a function on the THING symbol as property `thing-at-point'. That function is invoked, and what the return value was returned by `thing-at-point'. The two branches of the `if' in `thing-at-point' were thus not symmetrical (and intentionally so, so that it could return actual things, not just strings naming things). One branch could return anything - a THING at point; the other branch returned a string naming a thing at point. This meant that `thing-at-point' could return a list, symbol, etc. - things that are not strings. What is new (since Emacs 24.4) is that someone added this at the end of the definition of `thing-at-point', and made it pertain to _both_ branches of the `if'. In addition, they named the result of the `if' by the variable `text'. (when (and text no-properties) (set-text-properties 0 (length text) nil text)) They apparently paid no attention to the important `thing-at-point' behavior provided by the first `if' clause, and instead just assumed that the `if' always returned a string. IIUC, Emacs Dev (not I), has insisted that `thing-at-point' itself should always return a string, as opposed to what `form-at-point' (and functions defined using it) returns, which can be a THING (not just a string naming a thing). For one thing, this allows code calling `thing-at-point' to count on the result being a string (if a thing is found) or nil (if not). I see three possibly reasonable fixes for the bug introduced in Emacs 24.4: 1. Make `thing-at-point' always return a thing, as (IIUC) wished by Emacs Dev. Have it convert the result of the first `if' clause to a string. Anyone needing a real (non-string) thing can use `form-at-point' to get what they want. 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. Among other things (sic), this allows the first `if' clause to return a propertized string. 3. Make `thing-at-point', as before, return just what the firat `if' clause returns, if that clause is taken, except that if either clause returns a string then strip that string of text properties (if NO-PROPERTIES is non-nil). My understanding is that Emacs Dev has preferred that `thing-at-point' return a string, and that users should use `form-at-point' if they want something else. (I've adapted my own code to that preference.) If so, then #1 is probably the option of choice: Convert anything returned by (funcall (get thing 'thing-at-point)) to a string. Personally, I do not see why Emacs added arg NO-PROPERTIES, as anyone could always remove properties on a string result from `thing-at-point'. Dunno who added this arg, or why, but I don't see that it provides any advantage. (Perhaps the one advantage it has inadvertently provided is to raise the question again of whether `thing-at-point' should always return a string.)