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: Sun, 13 Nov 2016 18:43:52 -0800 (PST) Message-ID: 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> 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 1479091536 19269 195.159.176.226 (14 Nov 2016 02:45:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2016 02:45:36 +0000 (UTC) Cc: 21391@debbugs.gnu.org To: Dmitry Gutov , Eli Zaretskii , Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 14 03:45:30 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 1c67Gf-0001O1-9L for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2016 03:45:09 +0100 Original-Received: from localhost ([::1]:35931 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c67Gi-0007Nz-JN for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Nov 2016 21:45:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c67Gc-0007LU-UV for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2016 21:45:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c67GX-00055H-SF for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2016 21:45:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40849) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c67GX-000554-PV for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2016 21:45:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c67GX-0000Gv-JV for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2016 21:45: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, 14 Nov 2016 02:45: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.1479091444956 (code B ref 21391); Mon, 14 Nov 2016 02:45:01 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 14 Nov 2016 02:44:04 +0000 Original-Received: from localhost ([127.0.0.1]:56248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c67Fc-0000FM-9J for submit@debbugs.gnu.org; Sun, 13 Nov 2016 21:44:04 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:16645) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c67Fa-0000Ee-QJ for 21391@debbugs.gnu.org; Sun, 13 Nov 2016 21:44:03 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uAE2hu4T030431 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2016 02:43:56 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 uAE2htXw014430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2016 02:43:56 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uAE2hsbK024505; Mon, 14 Nov 2016 02:43:54 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:125679 Archived-At: > > I can suggest adding a new function, with the features you > > mention. We could even deprecate thing-at-point and advise > > to use the new one instead. >=20 > In this vein, I would propose deprecating `thing-at-point' in favor > of `bounds-of-thing-at-point', which should provide all the necessary > information for a `buffer-substring' call anyway (when it works). This is really going from bad to worse. But I can't say I'm surprised. Eli suggested to keep the behavior backward-compatible, rather than ensuring that the return value is a string. That is a reasonable approach. It's OK by me. It is the 2nd of the 3 approaches I described as reasonable=20 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D21391#52): 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. Can we please just do that, and stop f__ing with thingatpt? I also suggested that we do this, in that case: d> 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. That's important. The use of symbol property `thing-at-point' is one of the most important features of library `thingatpt.el'. Pointing out `thing-at-point' in the doc without pointing out this feature is letting users down. Each of the 3 approaches I described is reasonable. What is not so reasonable are the kinds of changes you are suggesting now. If you are really entertaining removing existing functionality then I would suggest you remove (deprecate) the NO-PROPERTIES argument that was added fairly recently. It is unnecessary, and its addition was apparently completely gratuitous. Did that action correspond to a bug fix or a user request? I cannot imagine that it did. Are we going to start adding a NO-PROPERTIES arg to _every_ function that can return a string? If not, why does it make sense here? How hard is it to remove the properties of a string?