From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Generalizing find-definition Date: Sat, 6 Dec 2014 10:38:47 -0800 (PST) Message-ID: References: <20141102151524.0d9c665c@forcix> <20141117211039.37f03409@forcix> <877fymghgb.fsf@bredband.net> <85ppc0qf9a.fsf@stephe-leake.org> <85zjb3o09d.fsf@stephe-leake.org> <85tx1amnyg.fsf@stephe-leake.org> <85egsem1u2.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1417891172 29535 80.91.229.3 (6 Dec 2014 18:39:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2014 18:39:32 +0000 (UTC) To: Helmut Eller , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 06 19:39:26 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XxKGJ-0002Fv-F6 for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 19:39:23 +0100 Original-Received: from localhost ([::1]:55214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxKGJ-0003Fv-2z for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 13:39:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxKFx-0002or-0u for emacs-devel@gnu.org; Sat, 06 Dec 2014 13:39:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxKFn-0000DF-1A for emacs-devel@gnu.org; Sat, 06 Dec 2014 13:39:00 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:42767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxKFm-0000Cm-QZ for emacs-devel@gnu.org; Sat, 06 Dec 2014 13:38:50 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB6IcmOp023271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Dec 2014 18:38:49 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6Icljl028966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Dec 2014 18:38:48 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6IclLi028950; Sat, 6 Dec 2014 18:38:47 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179201 Archived-At: > A problem seems to be that xref-identifier-at-point would need a > possibly complicated heuristic to determine if we are at such a > filename or a "normal" identifier. Maybe it's easier to have a > separate xref-file-name-at-point which would by default do what > ffap-guess-file-name-at-point does. For ELisp it should > additionally recognize (require 'foo) and somehow reuse find-library. And..., and somehow..., and..., and somehow... In general, this is the wrong approach, I think. Q. When does reuse of a file name or a URL or... at point make sense? A. As input to a command that acts on a file name or a URL or... The *particular command* already knows what kind of thing it expects. All that's needed, as a *general* mechanism, is a general way to pull text at point into the minibuffer. That's where the design effort should be, IMO. And this mechanism should be entirely decoupled from any particular use of the grabbed text. That's my main point here. In particular, `find-definition' itself might be misguided. I cannot really speak to whether it is, but that's my hunch. Doesn't a user know what kind of thing definition s?he wants to look up? Does s?he really need Emacs to guess what kind of thing is at point (a guess that is fraught with ambiguity)? The problem comes down, I think, to providing a key (or keys) that will *grab what the user wants at point*. We should then bind that key in `minibuffer-local-map' so that it is available *always*, regardless of the minibuffer-reading command and the particular way of reading (with completion or not, and for any kind of completion). There is room for imagination and invention here, and that is where the effort should be placed, IMHO. Let's suppose that we start by trying for just a single key - `M-.', for instance. Clearly, adding more "grab" keys would make it easier for a user to make known to Emacs what to grab, but it would also make users know more keys etc. We can always add more. Let's see what can be done with one, for starters. As food for thought, here is a description of what `M-.' does in Icicles, from the minibuffer. I don't claim that this is the full solution - at all. As I said, I think there is plenty of room for invention, to come up with good ways for a user to tell Emacs what thing(s) to grab at point. Icicles currently uses a single key, `M-.', to grab stuff into the minibuffer from point. You customize what your general preferences are in this regard. The choice you make is whether repeated use of `M-.' should, by default, grab (a) additional stuff of the same type or (b) alternative stuff of different types (i.e., replacing, in the minibuffer, what the previous invocation grabbed). You can override your general preference (alternatives vs more-of-the-same) on the fly when you use `M-.', by providing a prefix arg. For example, if you generally prefer that repeated `M-.' grab different kinds of thing at point (default behavior), then `C-u M-.' switches the behavior temporarily so that repeating `M-.' grabs successive occurrences of the same kind of thing. There is additional, more complex behavior available as well. You can customize the sequence of functions used to grab different kinds of thing. You can grab successive things of the same type to the left or to the right of point. You can grab alternative things at point and insert not the grabbed text but the result of evaluating it as a Lisp sexp. This page describes the behavior of `M-.' in Icicles: http://www.emacswiki.org/Icicles_-_Inserting_Text_from_Cursor And this part describes the details outlined above: http://www.emacswiki.org/Icicles_-_Inserting_Text_from_Cursor#RepeatedM. To be clear, I am not at all proposing this same behavior for Emacs. I point to it as food for thought. What I am suggesting is only this: 1. It makes sense to concentrate on coming up with a useful, general-purpose grab-text-at-point minibuffer command, not with a general-purpose `find-definition' top-level command. 2. What Icicles does in this regard might serve as some food for thought. But there are surely more and better possibilities. 3. Everything useful need not be combined in a single minibuffer command (such as Icicles tries to do with `M-.'). Having different, easily understood behaviors on separate keys can also be a good way to go. HTH.