emacs-devel
[Top][All Lists]
Advanced

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

Re: project-find-file: switch to include non-tracked files


From: Manuel Uberti
Subject: Re: project-find-file: switch to include non-tracked files
Date: Wed, 6 Oct 2021 07:18:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 05/10/21 21:47, Dmitry Gutov wrote:
It kind of got lost among other issues, sorry. That's doubly easy to do with emacs-devel threads, so if you could use Debbugs for feature requests in the future, that would be great.

Do you want me to move the discussion on Debbugs?

Now, I've whipped up a small POC. See the attachment, try it out.

Since 'find' without ignore instructions is as fast as 'git ls-files' (even faster, in my testing, on my machine), it didn't require any changes in the API so far.

Thank you. I gave it a try and it works as expected.

But is that the behavior we want?

Currently it lists _all_ files in the directory, including, say, all contents of .git/ (of which there can be a lot, depending on the project, whether it uses 'git flow', etc).

Should we add the common ignores from vc-directory-exclusion-list? To simply filter those dirs out?

Maybe something else too? Like grep-find-ignored-files (it lists common compiled/object files which one usually doesn't want to search, or even visit)?

Combining the vars above would bring the file listing to the default 'project-ignores' behavior. Which the 'transient' backend uses, for example.

I think ignoring directories such as .git would be good to speed up the command and make the candidate list cleaner.

But in the previous iteration of this thread you also referred to Helm's 'C-c i' behavior. Does it only list the ignored files?

'C-c i' in helm-ls-git toggles the '-o' switch for git ls-files, so it does not include the listing of the .git directory in its result.

In any case, we could make 'C-u project-find-file' have this behavior: listing only ignored files instead. And maybe not all of them: skipping the contents of .git/, .bzr/, etc, still sounds useful. The upside is possibly having a lot fewer files to choose from.

I agree with you.

--
Manuel Uberti
www.manueluberti.eu



reply via email to

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