From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Sun, 07 Dec 2014 10:52:45 -0600 Message-ID: <85388rfllu.fsf@stephe-leake.org> 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 X-Trace: ger.gmane.org 1417971201 29547 80.91.229.3 (7 Dec 2014 16:53:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 16:53:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 07 17:53:14 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 1Xxf57-00046K-12 for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 17:53:13 +0100 Original-Received: from localhost ([::1]:58467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xxf56-0007u5-Ms for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 11:53:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xxf4p-0007tu-4F for emacs-devel@gnu.org; Sun, 07 Dec 2014 11:53:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xxf4j-0001Du-Fp for emacs-devel@gnu.org; Sun, 07 Dec 2014 11:52:55 -0500 Original-Received: from dnvrco-outbound-snat.email.rr.com ([107.14.73.230]:17214 helo=dnvrco-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xxf4j-0001DM-Ai for emacs-devel@gnu.org; Sun, 07 Dec 2014 11:52:49 -0500 Original-Received: from [70.94.38.149] ([70.94.38.149:53315] helo=TAKVER) by dnvrco-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 13/64-16169-FD584845; Sun, 07 Dec 2014 16:52:47 +0000 In-Reply-To: (Drew Adams's message of "Sat, 6 Dec 2014 10:38:47 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt) X-RR-Connecting-IP: 107.14.64.142:25 X-Authority-Analysis: v=2.1 cv=W762VHmk c=1 sm=1 tr=0 a=AppmJ/7ZOOFWL/q6u6u93g==:117 a=AppmJ/7ZOOFWL/q6u6u93g==:17 a=ayC55rCoAAAA:8 a=fNEgcOh0sVsA:10 a=9i_RQKNPAAAA:8 a=yPCof4ZbAAAA:8 a=dxfYD-vCcQWxtHF8pRoA:9 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 107.14.73.230 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:179279 Archived-At: Drew Adams writes: >> 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. Not in my use case. I'd like to have one "goto ref" key that Does the Right Thing as much as possible. That way I don't have to remember different keys for different cases. > Doesn't a user know what kind of thing definition s?he wants > to look up? Yes, but I don't want to _also_ have to know which key to invoke. > Does s?he really need Emacs to guess what kind of thing is at point Not "guess", no. Determine precisely, yes. > (a guess that is fraught with ambiguity)? If Emacs can't figure it out, put up a list of possibilities, or report error. This works very well for me. I have three related keys for this kind of thing (Emacs isn't quite as intelligent as I'd like yet); C-c C-d for symbols, whose behavior is mostly determined by the compiler generated cross reference info; now bound to 'xref-find-definitions'. C-F11 for files, whose behavior is determined by parsing the string at point, influenced by the major mode. Mostly a wrapper around ff-find-the-other-file. C-F12 whose behavior is totally determined by parsing the string at point or active region, via an alisp of regexps. Sometimes the "at-point" version does the wrong thing; then the "active region" version does what I actually want (and vice versa). I started the current discussion (I changed the Subject line) to cover implementing the C-F12 functionality in a more general way, or just make it available in Emacs core or an ELPA package. It might also make sense to make the C-F11 functionality available in Emacs core. > The problem comes down, I think, to providing a key (or keys) > that will *grab what the user wants at point*. Thing-at-point does that pretty well, and xref-identifier-at-point provides a way to extend that. I'm talking about what to do with the string after we get it, and to some extent UI design to give more information to Emacs about what to get and what to do with it (at point vs region, for example). > 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). This might make sense, but that requires being in a prompt in the first place; I try to avoid that whenever possible. > 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. We disagree; that's fine. -- -- Stephe