Only check for TODOs in files tracked by the tree view

[ghost]

Hi !

First of all, great job with this package ;) It's very useful and I use it everyday but here is a 'little' enhancement that would be great.

I have a project that use a LOT of extern libraries which also have TODOs and FIXMEs etc... Because of that, when I search for TODOs etc.. I have to read everything and find mines and this is hard job to do.

So, it would be great for this package to ignore files that are NOT in the tree view i.e files ignored by a .gitignore file AND files excluded from the tree view (with the ignored names option).

[mrodalgaard]

I'm not sure I understand why this is not working for you.

The current implementation acts as explained in readme under ignoreThesePaths.

• If the file is not in your tree view, it is not scanned unless open and using the find-in-open-files command instead of the normal find-in-project command.
• If the current project is a valid git repository and Exclude VCS Ignored Paths is checked, it will skip the files/folder defined in .gitignore.
• If Ignored Names from atom core settings is defined, it will skip these files as well.

What action are you seeing that contradicts this?

[ghost]

Ok, so with the current implementation, it should work as I want... But it doesn't (at least for me).

The issue is maybe (for now I don't see any other reason) that I have a 'complex' .gitignore file (with many files and folder excluded) and the tree view has this issue :

.gitignore cascaded negations not working correctly #196
atom/tree-view#196

I managed to write I .gitignore file that works for both atom and git (see last comment
atom/tree-view#196 (comment)). However when I use find-in-project command, files not highlighted in the tree view (i.e not tracked by git) are not skipped.

[mrodalgaard]

Wow, that is a complex .gitignore you have ended up with. It is most likely the negations that fails with Atom, as it is not something I have observed before.

I use workspace.scan to search the workspace, which takes care of ignores defined in .gitignore, so you should probably open a ticket there or follow the ticket in tree-view.

I do not think it is something I can fix from my package. But I might be wrong.