[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: find-file-project

From: Stephen Leake
Subject: Re: find-file-project
Date: Sat, 09 Jan 2016 06:18:36 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

Dmitry Gutov <address@hidden> 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

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 
                :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 <ret>. otherwise I hit <right>

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]