Re: find-file-project

[Dmitry Gutov]

On 09/17/2015 12:01 AM, Stephen Leake wrote:

> That's what the "..." is supposed to mean. I guess I was not being
> "really clear". Sorry.

In see. In hindsight, it should've been obvious to me, though.

> In the following, let's assume that "..." is "c:/project1".

Ok.

> > Indeed, the logic should be pretty similar. But the external
> > project-search-path entries usually doesn't have any ignored
> > directories, whereas there are often ignored dirs inside
> > project-roots, usually configured via .gitignore or the project file.
>
> You've lost me here.

You've asked about the difference between project-roots and 
project-search-path. Anyway, it's not too important here.

> There is an ignored dir in this example; c:/project1/dir2/dir21/obj/.
>
> Is that supposed to be in the result of project-ignores or not?

Sure.

> Does this mean file name completion should search on project-roots, not
> project-search-path, for this use case?

Err, that looks like a non-sequitur to me. project-find-file should 
search in where it's defined to search (up to you). It just occurs to me 
that some users might expect it to only list files in the currently 
opened project(s), whereas other users would like to jump to system 
include files as well.

> xref-find-regexp searches on both, which is redundant. For example, for
> a file in Emacs core, using only project-try-vc in project-find-files,
> project-roots returns ("c:/Projects/emacs/master/"), and
> project-search-path includes that directory along with others.

It's kinda redundant, but as long we define project-search-path as a 
list of directories with *source* files, it may omit the root 
directories if they contain only, say, documentation. But we want 
xref-find-regexp to search in documentation as well.

> As we have discussed, in general a recursive path requires ignored
> directories in order to be accurate. So since project-search-path is
> recursive, it must always be used together with ignores; that means

I don't see your point. Yes, ignores should be used, but only when there 
are ignores. "Flat" search path will have to use ignores as well 
("dir3/dir31/*.dvi" is a good example).

> project-ignores must return c:/project1/dir2/dir21/obj/ in this example.

You can have it return the absolute files names, but it's quicker to 
relative, "rooted" ignores.

> Sorry, I need "yes" or "no"; this either meets the spec (and intended
> semantics) of project-ignores, or it doesn't.

I would like to amend my answer: no, it's incorrect.

(project-ignores ".../dir3") should return ignores relative to that 
directory. So "./dir3/dir31/*.dvi" would be "./dir31/*.dvi" instead.

Or return absolute file names, they would work as well.

> > Or you could simply return the whole list each time, and
> > leave it to 'find' to apply the ignores appropriately. Not sure what
> > the performance hit will be. There might be false positives as well.
>
> I'm guessing this means "yes, it meets the intended semantics".

Aside from the detail above, yes.

> Hmm. I had not considered that approach. It could well be that spawning
> "find" is faster than iterating over the disk in elisp.

It's been tried, and it's definitely faster, especially for larger projects.

> However, I don't want to rely on "find.exe" on Windows boxes, so I'll
> stick with an all elisp solution.

I would urge you to reconsider: we assume the presence of 'find' 
already. M-x rgrep is probably the most common command that relies on 
it. Or M-x find-dired.

> I guess you are also saying that the elisp functions for getting a list of
> files in a directory will return absolute paths, so this will actually
> be comparing "./dir2/dir21/obj/"
> to "c:/project1/dir2/dir21/obj". Which can be accomplished by first
> expanding the glob pattern relative to the current root.
>
> That would be one way to implement it.

Yes, if you insist on processing it in Lisp.

> > Thank you. I was hoping you'd come to that conclusion.
>
> You could have been more constructive in getting there.

If you mean the small jab about Ada, I grew impatient about having to 
reiterate what we've already established about Emacs Lisp. Sorry?

Or do you mean something else? I've suggested to use completion-at-point 
from the outset.