[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: Thu, 17 Sep 2015 20:45:26 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0

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


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?


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.

reply via email to

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