[Top][All Lists]

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

Re: find-file-project

From: Dmitry Gutov
Subject: Re: find-file-project
Date: Fri, 8 Jan 2016 00:12:26 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0

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

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).

reply via email to

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