Re: find-file-project

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 09/16/2015 03:56 PM, Stephen Leake wrote:
>
>> One question; what does "To root an entry, start it with `./'.  " mean?
>> How does that affect the intended matching?
>
> That means that ./f* matches ./foo, but not ./bar/foo (these are paths
> relative to the root).

By "root" I guess you mean the argument "dir", since that is an element
of the recursive project-search-path.

To be very clear, suppose we have this directory structure:

dir1/
    dir11/
        file1.el
        file1.elc

dir2/
    dir21/
        obj/
        Makefile
        foo.exe
        bar.exe
        test_1.text
        test_2.text

    dir22/
        able.exe

dir3/
    dir31/
        file3.texi
        file3.dvi
        file4.text

project-search-path returns (".../dir1" ".../dir2" ".../dir3"); thus
project-ignores is only called with one of these three values. (I'm
ignoring project-roots, because I don't understand when it would be
different from project-search-path).

The user wants to ignore "*/*.elc", "*/*.dvi", "*/*.exe",
"dir2/dir21/obj/*", "dir2/dir21/*.text", "dir3/dir31/*.dvi".

So one implementation of project-ignores could be:

(cond
 ((string-equal dir ".../dir1")
  '("*.elc" "*.dvi" "*.exe"))

 ((string-equal dir ".../dir2")
  '("*.elc" "*.dvi" "*.exe" "./dir2/dir21/obj/" "dir2/dir21/*.text"))

 ((string-equal dir ".../dir3")
  '("*.elc" "*.dvi" "*.exe" "./dir3/dir31/*.dvi"))

)

A real project implementation would use an alist or hashmap.

Then find-file-path-completion-table could take a recursive
project-search-path as the "path" argument, and recurse thru the
directory tree, calling project-ignores at each directory, with a parent
directory from project-search-path as the argument, and comparing the
path of each file - relative to the parent directory - to the glob
patterns.

For example, when processing dir2/dir21, it calls (project-ignores
"dir2"), and compares "./dir2/dir21/obj/" to "dir2/dir21/obj", and
"*.exe" to "dir2/dir21/foo.exe", both yeilding "ignore".

Is that right?


I gather this was designed to match the semantics of find? I don't see
any uses of project-ignores in the current code, but it could be used
with find-grep in a project-aware xref.

Since the compare for directories is different from that for files, it
would simplify the use of project-ignores (at least for this use case)
if it was split into project-ignore-files and project-ignore-dirs. Or
took an arg to specify that. But I'll use it as is, and see how much
that would really gain.


I was stuck on using a flat path for find-file-path-completion-table
because I started out trying to reuse locate-file-completion-table. But
now that I'm implementing the completion function from scratch, and it
is reading the disk and ignoring some files anyway, it does make more
sense start with a recursive path.

--
-- Stephe