Re: find-file-project

[Stephen Leake]

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

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