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: find-file-project Date: Sat, 09 Jan 2016 06:18:36 -0600 Message-ID: <86d1tb54kj.fsf@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <55F8F2FA.6060902@yandex.ru> <867fnq1oe9.fsf@stephe-leake.org> <55F9A13A.3070101@yandex.ru> <55FB01BD.1070909@yandex.ru> <568C6DE5.8040201@yandex.ru> <86egdt982b.fsf@stephe-leake.org> <568EADC5.2030604@yandex.ru> <86oacx6u1e.fsf@stephe-leake.org> <568ED4BA.4030108@yandex.ru> <86a8of7up3.fsf@stephe-leake.org> <56904AF9.3050906@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1452341956 7588 80.91.229.3 (9 Jan 2016 12:19:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 12:19:16 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 09 13:19:04 2016 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 1aHsU4-0003LK-6F for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 13:19:04 +0100 Original-Received: from localhost ([::1]:40293 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHsU3-0000n0-Lc for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 07:19:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHsTz-0000mu-1B for emacs-devel@gnu.org; Sat, 09 Jan 2016 07:18:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHsTu-00066R-0w for emacs-devel@gnu.org; Sat, 09 Jan 2016 07:18:58 -0500 Original-Received: from gproxy5-pub.mail.unifiedlayer.com ([67.222.38.55]:48839) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1aHsTt-00066I-Pp for emacs-devel@gnu.org; Sat, 09 Jan 2016 07:18:53 -0500 Original-Received: (qmail 24371 invoked by uid 0); 9 Jan 2016 12:18:50 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 9 Jan 2016 12:18:50 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id 3oJn1s0052UdiVW01oJqPg; Sat, 09 Jan 2016 05:18:50 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=7aQ_Q-yQQ-AA:10 a=vaJtXVxTAAAA:8 a=RJG9qvXRNp4NDEuGF_UA:9 Original-Received: from [76.218.37.33] (port=52913 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1aHsTm-0004u9-T3; Sat, 09 Jan 2016 05:18:47 -0700 In-Reply-To: <56904AF9.3050906@yandex.ru> (Dmitry Gutov's message of "Sat, 9 Jan 2016 02:49:13 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.38.55 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:197901 Archived-At: Dmitry Gutov writes: > On 01/08/2016 10:11 PM, Stephen Leake wrote: > >> Hmm? the doc string of `locate-uniquified-file' says "return an >> absolute-filename", not "visit a file". > > Sorry, I got confused. I looked for an interactive function to > showcase the logic, and there were only two of them. And only the > first one actually worked interactively. > >>> As written, though, it only lists files at the top-level of load-path, >>> without recursing. >> >> Yes, that's consistent with `locate-file', and all other uses of >> `load-path'. > > I suppose so. > > It's not how I'd imagine a `project-find-file' command to work. > >> To add all directories that contain elisp files, you need to build the >> path iterator directly: > > I would hesitate to ask that of every user. What is the alternative? Only the user knows which directories in load-path should be treated recursively. I do have a special function for elisp: (defun elisp-find-file (filename) ;; see also sal-project-find-file below "Prompt for an elisp file name, find it on load-path exteded with cedet/**." (interactive (list (when current-prefix-arg (thing-at-point 'filename)))) (let* ((cedet (file-name-directory (locate-library "cedet"))) (iter (make-path-iterator :user-path-non-recursive load-path ;; contains cedet, but not cedet/* :user-path-recursive (list cedet)))) (find-file (locate-uniquified-file-iter iter nil filename "elisp file: ")) )) That assumes only CEDET is handled recursively; if I add another project that has recursive dirs, I'll have to add that to this function. >> But once you get used to it, you'll find that you simply don't care >> about the directory; you really only need it to disambiguate colliding >> names. So the suffix style makes sense. > > One drawback of your method is that I don't know what to type, in > advance. The necessary entry might have duplicates (and thus, a > disambiguating prefix/suffix), or it might not. So it's hard to > navigate to a file based on muscle memory alone. I don't follow. If "locate.el" has duplicates, but I don't know that, then I start by typing "loc", and the completion shows both completions, with disambiguating suffix. If the first one is the one I want, I hit . otherwise I hit . That's the same pattern needed to distinguish "filter.el" from "filters.el", except the disambiguation in the first case happens to include directories. If we used prefix directories, there might be a problem; depends on the details. On the other hand, with your implementation, I'm required to type "ede/locate.el" vs "locate.el" to find these two files. So I have a problem; I don't want to have to memorize all the files in ede, srecode, and semantic! -- -- Stephe