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: Wed, 16 Nov 2016 06:45:11 -0800 (PST) Message-ID: References: <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 1479307576 30802 195.159.176.226 (16 Nov 2016 14:46:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 16 Nov 2016 14:46:16 +0000 (UTC) To: andreas.roehler@easy-emacs.de, 21391@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 16 15:46:11 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 1c71TW-0006qr-Ig for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2016 15:46:10 +0100 Original-Received: from localhost ([::1]:52935 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c71TZ-00029d-PN for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2016 09:46:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c71TS-00029L-Ew for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 09:46:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c71TO-0005f8-GW for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 09:46:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43522) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c71TO-0005eV-Cf for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 09:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c71TN-0007TK-IK for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 09:46: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: Wed, 16 Nov 2016 14:46: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: X-Debbugs-Original-To: Andreas =?UTF-8?Q?R=C3=B6hler?= , bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.147930753728688 (code B ref -1); Wed, 16 Nov 2016 14:46:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 16 Nov 2016 14:45:37 +0000 Original-Received: from localhost ([127.0.0.1]:58921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c71Sy-0007Sd-KC for submit@debbugs.gnu.org; Wed, 16 Nov 2016 09:45:36 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34181) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c71Sv-0007SP-RL for submit@debbugs.gnu.org; Wed, 16 Nov 2016 09:45:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c71Sp-0005R9-NW for submit@debbugs.gnu.org; Wed, 16 Nov 2016 09:45:28 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:59414) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c71Sp-0005R5-Jh for submit@debbugs.gnu.org; Wed, 16 Nov 2016 09:45:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c71So-000285-Dx for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 09:45:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c71Si-0005PC-Qa for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 09:45:26 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:24408) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c71Si-0005OO-Ik for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 09:45:20 -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 uAGEjE9l006864 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2016 14:45:14 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 uAGEjEoG017448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2016 14:45:14 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uAGEjC46025506; Wed, 16 Nov 2016 14:45:13 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-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:125753 Archived-At: > > Thing-at-point has been, from the outset, about actual Lisp > > THINGS, not just strings that name such things. Yes, > > string-naming-a-thing is a common use case - the most common, > > currently. But it is only part of the story. > > > > And yes, buffer text is usually examined to come up with > > the returned THING. But the buffer text need not be > > examined. What is most significant is point - the buffer > > position. And even that could be ignored by the function > > that comes up with an appropriate THING to return. > > > > thingatpt.el is much more general, and offers many more > > possibilities, than just grabbing some text at or near > > point. >=20 > Agreed so far, understand that. > My point is to suggest a restriction here, making the use easier. What difficulty in use to you see? What is the difficult-use problem you are trying to solve? > If a symbol might return an arbitrary thing doing arbitrary > actions, why it should reside in this library? Users of thingatpt.el, including code that uses its features, will use functions to do THING-related things. Any "arbitrary" functions used to come up with an appropriate thing are not, in practice (i.e., in the real world) not arbitrary. They are designed to return a Lisp THING usefully. And yes, this is all about obtaining a THING at point. > Beside this - upholding that in the core, a string is the result in > any case first. Follows functions which operate on this string, It's hard for me to parse what you're saying, but I think your point is only that buffer text at point is the origin of coming up with a THING. That does not at all imply that the THING result is a string. > derive from its representation a number, intern it or whatever. What's "its"? All that serves as input to the function is point and a buffer (and any global Emacs context - windows etc.). It is precisely up to the "arbitrary" function to decide just what part of that (humongous) "its" input it uses as relevant, and it is up to that function to decide how to use it and what THING to return. > For clarification IMO it would be better to separate these > use-cases from the core-thing. There is no "core-thing". The buffer text is only an input. It is not the THING that is returned. And even in the case where a string taken from the buffer text is returned, which string? which bit of buffer text? That's the point. There are an infinite number of THINGs that the function could return. And even picking some buffer text as the (string) THING to return, there are a myriad (but in this case not infinite) different string THINGS taken from buffer text that it could return. There is NO "core-thing". It is always up to the function (even in the case of a string return) to decide what to return and how to obtain it. > These use-cases are plain operations on strings, nothing > special to thing-at-point. There are no "core" or special use cases. There is nothing special or more "core" about returning a string value, whether or not that string is a subsequence of buffer text.