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 08:24:30 -0800 (PST) Message-ID: <5a6ddd21-ebf9-42bf-9fb6-7fc9e037b3ed@default> 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>> 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 1479140743 29259 195.159.176.226 (14 Nov 2016 16:25:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2016 16:25:43 +0000 (UTC) Cc: tino.calancha@gmail.com, dgutov@yandex.ru, 21391@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 14 17:25:39 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 1c6K4V-0005gp-7W for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2016 17:25:27 +0100 Original-Received: from localhost ([::1]:41206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6K4Y-0004S2-AF for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2016 11:25:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6K4B-0004DN-2p for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 11:25:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6K47-0001O1-4m for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 11:25:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41894) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c6K47-0001Nf-0z for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 11:25:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c6K46-0005q3-CR for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2016 11:25: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: Mon, 14 Nov 2016 16:25: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.147914068422416 (code B ref 21391); Mon, 14 Nov 2016 16:25:02 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 14 Nov 2016 16:24:44 +0000 Original-Received: from localhost ([127.0.0.1]:57293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6K3o-0005pU-CA for submit@debbugs.gnu.org; Mon, 14 Nov 2016 11:24:44 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:44977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6K3m-0005pG-CY for 21391@debbugs.gnu.org; Mon, 14 Nov 2016 11:24:42 -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 uAEGOZfI018362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Nov 2016 16:24:36 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id uAEGOYB4025437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Nov 2016 16:24:35 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id uAEGOWQu026216; Mon, 14 Nov 2016 16:24:32 GMT In-Reply-To: <<83a8d2hy8f.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:125691 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. >=20 > 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. That is the point of allowing such a function: to let you control the behavior from outside function `thing-at-point'. This is similar to passing a function-valued optional parameter and calling that to provide the behavior. That's the point of the original design of `thing-at-point': (1) provide a default, string-producing behavior and (2) also allow for another function to define the behavior for particular types of THING. > If thing-at-point is called with NO-PROPERTIES non-nil, and the > thing-at-point property returns a string, then any properties > should be removed from that string, exactly as in the other case. That overrides the intended behavior of the THING function. It removes its control, which is there by design. Sure, you can say that if a caller provides NO-PROPERTIES then s?he always wants a string value to have properties removed. I agree that this is not a problem (since the arg is optional, and new). However, I really see no reason for NO-PROPERTIES to have ever been added. What were we thinking, to do such a thing? I cannot imagine a good reason for that change, even if the arg is optional. We don't add optional args willy nilly just because they don't do any harm if they're not called. And we certainly don't add a NO-PROPERTIES arg to every function that can return a string. What is so special about this function, that it needs such a "feature"? I haven't seen an answer to this question yet. I seriously would propose that we deprecate that optional arg and return to what was there before it was introduced, along with this bug. That was a misguided change, IMO. It is perhaps no accident that whoever added it introduced this bug at the same time. I suspect that the change betrays a poor understanding of thingatpt.el. > I don't see why we should single out that one use case. > I think the only change that makes sense at this point is to replace > sequencep by stringp, as Tino originally proposed. Other than that, > there are no problems here that we need to solve. I'm OK with that, too. That was my #3 "reasonable solution": d> 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). Fine by me.