From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21391: 24.5; `thing-at-point' should return a string Date: Thu, 10 Nov 2016 18:08:49 +0200 Message-ID: <83bmxnfhbi.fsf@gnu.org> 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> <83y40sfyij.fsf@gnu.org> <76505436-e66c-0ed3-6d7a-ce654f38ef30@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1478794970 3825 195.159.176.226 (10 Nov 2016 16:22:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Nov 2016 16:22:50 +0000 (UTC) Cc: tino.calancha@gmail.com, 21391@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 10 17:22:46 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 1c4s7O-0006rx-8k for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Nov 2016 17:22:26 +0100 Original-Received: from localhost ([::1]:47499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4s7R-0003zD-BG for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Nov 2016 11:22:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4ruV-000779-T5 for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:09:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4ruQ-00051Y-7z for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:09:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37035) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4ruQ-00051M-4a for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c4ruP-0008Px-Tv for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2016 16:09: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.147879414032349 (code B ref 21391); Thu, 10 Nov 2016 16:09:01 +0000 Original-Received: (at 21391) by debbugs.gnu.org; 10 Nov 2016 16:09:00 +0000 Original-Received: from localhost ([127.0.0.1]:52434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4ruN-0008Ph-TG for submit@debbugs.gnu.org; Thu, 10 Nov 2016 11:09:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41869) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4ruM-0008PS-IE for 21391@debbugs.gnu.org; Thu, 10 Nov 2016 11:08:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4ruC-0004r2-Ee for 21391@debbugs.gnu.org; Thu, 10 Nov 2016 11:08:53 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4ruC-0004qu-BJ; Thu, 10 Nov 2016 11:08:48 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4738 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c4ruB-0006uh-Pk; Thu, 10 Nov 2016 11:08:48 -0500 In-reply-to: <76505436-e66c-0ed3-6d7a-ce654f38ef30@yandex.ru> (message from Dmitry Gutov on Thu, 10 Nov 2016 01:30:20 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:125553 Archived-At: > Cc: tino.calancha@gmail.com, 21391@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 10 Nov 2016 01:30:20 +0200 > > See the attached patch. > > Or to take a step further, we might want to deprecate the > `thing-at-point' property, and recommend to only use the > `bounds-of-thing-at-point' property. This way, we get the string-ness > guarantee automatically, and the bounds-of-thing-at-point function will > work for all things (it currently fails for `number'). > > >>> 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? > >> > >> To make thing-at-point behavior more consistent. > > > > It is consistent now. > > Put point on a number. Number is a sexp. Not all sexps are strings. > > (thing-at-point 'number) => 123 > (thing-at-point 'sexp) => "123" > > That doesn't looks consistent to me. There's a tension here between consistency and backward compatibility. And since this function was "inconsistent" for a very long time, I'm not sure losing backward compatibility can be justified by consistency at this point. We'd also lose something else: some Lisp objects can be printed, but their printed representation cannot be read back. So for some objects, requiring thing-at-point to return a string would lose information. > > The only way to make it inconsistent is to have > > a 'thing-at-point' property that violates that, but we never do that > > in Emacs proper, so if someone else does that, it would be their bug. > > number's `thing-at-point' property is not like the others. Right, I succeeded to forget that since the beginning of this thread.