Re: find-file-project

[Dmitry Gutov]

On 01/07/2016 10:58 PM, Stephen Leake wrote:

> > Thanks, I'll have to play with it.
> >
> > Does it handle ignores?
>
> Yes, in the path iterator object.

Tried it, and it did what advertised after I added (find-file ...) to 
the locate-uniquified-file's definition. Has some issues (type `<emacs', 
press TAB, get "Internal error: xxx doesn't match yyy"), but it's not 
too important at this stage.

As written, though, it only lists files at the top-level of load-path, 
without recursing. So it's hard to compare it with project-find-file 
that uses the find program.

Note that it doesn't list lisp/cedet/ede/locate.el that you brought up 
as an example earlier (maybe because I don't have EDE loaded).

FWIW, I'm not partial to the suffix-style of uniquification.

> > How's the performance in the Emacs repository?
>
> There is a noticeable delay, mostly due to computing the partial
> completion (before I added that, there was no noticeable delay).

Did you try that using an iterator that visits the whole of Emacs repo, 
not just load-path? E.g., I can't visit xdisp.c this way.

> This is a pure elisp implementation. However, the path iterator object
> could provide the directory list to the subprocess find function as
> well.

Will Emacs then call `find' for each of the "shallow" directories in the 
list? That seems inefficient. Feel free to prove me wrong here, of course.

I've been thinking about how we could deletage file-listing (as well as 
completion, even) to an external tool, so that Emacs can manage to 
navigate huge projects.

It could be a generic method which returns a value similar to EDE's 
locate-obj (to support a set of operations we'd dispatch: list files, 
list directories (both with completion), search through files...).

But as a first draft, let's imagine having it simply return a list of 
files in a directory. Certain backends could implement that to traverse 
some of their "roots" non-recursively. But I think this will only work 
okay if the list of roots is not too long (that is, converting recursive 
dirs into non-recursive, anywhere, doesn't fit this approach).