Feature request #1732: Search through file names

Comments

1. Greg Hurrell 2010-11-09T10:39:14Z

   I have a pretty big folder with source files (about 30000 files). There are a lot of subfolders with names I'm not interested in. Is it even possible to search through filenames only?

   I gather from this that you mean that if you type "foo", for example, only the filename part of the path would be searched so "a/b/c/foo.txt" would be considered a match but "foo/hello.txt" would not. Is that right?

   If that's the case, see ticket #1516. The short version is: Command-T is designed to use a "path-centric" mentality and not a "filename-centric" one. So if you're thinking in terms of filenames only, it's not going to be the right tool for the job. You either need to change your mindset, or change your tool. (And I'd suggest changing your mindset, as thinking in a "filename-centric" way when you're looking for one file among 30,000 is unlikely to be effective.)

   You might also want to check out this forum topic, which specifically talks about searching massive hierarchies.

   Having said that, you have three options here:

   1. Use Vim's 'wildignore' setting to tell Command-T which subfolders should be ignored. One nice benefit of this is that other file-opening mechanisms in Vim will also ignore the same files (it also means that this really is only for stuff that you never want to open). See the help (:h command-t-wildignore and also :h 'wildignore') for more info.
   2. If you want to really focus on a specific sub-area of your project, you can reduce the scope of Command-T's search by providing it with a specific starting path argument (eg. :CommandT path/to/some/subdirectory).
   3. Use a different plug-in which does use a "filename-centric" philosophy — for example, you could use FuzzyFinder in conjunction with a searchstring like "**/foo" — but I would recommend that you try embracing the "path-centric" mindset first as I really do think it's more effective (that's why I wrote Command-T in the first place, after having tried the alternatives and not being satisfied with them).

   Actually, I use http://www.wholetomato.com/products/features/fis.asp a lot. It would be nice to get some features in Command-T.

   E.g. I miss multiple file opening (when you search for Foo, find files Foo.h and Foo.cpp, and then select and open them simultaneously).

   Can you please file separate tickets for each request, so that nothing gets overlooked?

   As far as that specific feature you mention, I'm not really sure if it first with the Command-T way. The tool is optimized to help you open that one file which you know you want, but which happens to be buried in a project among a bunch of others, and you want to get to it as fast as possible. There are plug-ins like the excellent a.vim for opening alternate files (eg. opening the header when you're looking at the implementation, and such), and other plug-ins extend that functionality (for a good example, see how rails.vim adds the ability to easily jump between models, views and controllers and such).

   In the 30,000 file project you mention, I'll bet that if you type "Foo" you'll get a lot more than just two results returned. How many of them would you want to open? 2? 3? 10? How likely is it that the top 10 results will contain the exact file you want?

   I think a better way to operate would be just open the file you want to work on right now, and then open the alternates when you want to edit them (either with a.vim or with Command-T). Note that I am planning on adding buffer navigation to Command-T (ticket #1608) in the future, so this will make jumping between already open files easier.

2. anonymous 2010-11-09T11:49:39Z

   OK, I see.

   It seems Command-T is just a fast way of navigation through well-know hierarchies. Like a turbo jump to /usr/local/bin by firing ulb. Anyway, you can't do that as you will stuck with / scanning :-)

   Sorry, but "path-centric" mindset seems pretty useless to me. Actually, most of files in our project have unique names. And I don't remember those names (tens of thousands). Sure, I don't remember most of folder names (thousands of them). I just remember that we have, say, notification broadcaster, somewhere. So, I just type "broad notif" and got the correct result like: SynchNotificationBroadcastingEngine.h/cpp and similar files. Here it is.

   Possible, "path-centric" is good enough for pretty small projects or middle-sized web projects with lots of the similar filenames like index.html :-)

   Anyway, thanks a lot for you answer and work. Vim became a lot better with Command-T.

3. Greg Hurrell 2010-11-09T16:44:00Z

   Sorry, but "path-centric" mindset seems pretty useless to me. Actually, most of files in our project have unique names. And I don't remember those names (tens of thousands). Sure, I don't remember most of folder names (thousands of them). I just remember that we have, say, notification broadcaster, somewhere. So, I just type "broad notif" and got the correct result like: SynchNotificationBroadcastingEngine.h/cpp and similar files. Here it is.

   Well, I think you've got it back to front. It is precisely in your type of project that a path-centric mentality will help you navigate faster than you could with just file names.

   As you said, there are fewer folder names than there are file names, so by definition they are "rarer" and therefore more valuable, statistically speaking, as a means of specifying location. Include some letters from your path, and you'll narrow down the list of possible results much faster. Note that you don't have to spell out the entire path; pretty much any characters you supply from the earlier path components will be better than not specifying any at all (ie. just say it is a file inside spec/controllers/admin/notifications/, you don't have to spell out "specconadmnot"; including any substring from there will help narrow things down). Also note that some positions in the path are weighted more highly than others (eg. searching for "ab" will rank annotated_bank more highly than delegate_subdomain), so you should try to enter characters which appear after slashes, underscores, hyphens and such.

   I honestly think that if you actually used the tool the way it is meant to be used that you'd find it to be the best way to get things done.

   I do wonder about how your 30,000 file project must be organized, if you have no notion of where files appear in its hierarchy. Don't you have things organized in modules or anything like that?

4. Greg Hurrell 2015-04-10T05:51:47Z

   Status changed:

   • From: new
   • To: closed

5. Greg Hurrell 2015-04-10T05:52:24Z

   Closing as a "won't fix" kind of thing.

   The ability to open multiple files at once is also kind of handed via the quickfix binding (<C-q>).

Add a comment

Comments are now closed for this issue.