Does Command-T support wildcards?

  1. anonymous

    It's a great plugin, but I have not found anything on wildcards support in the docs. For example, ability to partially supply file name: 

    *File*Should*Contain*This*

    will find all files that contain words File Should Contain This in that order and anything in between them.

    Is this supported in Command-T currently?

  2. Greg Hurrell

    There is no need to use explicit wildcards as when you type: 

    FileShouldContainThis

    it will match those chars anywhere in the path. (Note that you should include some letters from the path, not just the filename, so that you narrow down the possible result set more quickly.) In other words it is if there were implicit wildcards between each pair of letters: 

    *F*i*l*e*S*h*o*u*l*d*C*o*n*t*a*i*n*T*h*i*s*

    And Command-T will exhaustively search for the highest-scoring way of matching that search string against all the paths in the project. This means that runs of consecutive characters will tend to score more highly, intuitively giving what you are most likely looking for.

  3. anonymous

    Sure, I noticed that after some use. However, because of this way of matching I usually get things that I don't want as top hit even when I type full file name.

    I work on a large (over 3 million lines of code) project with over 57,000 relevant files (and up to 3 times as many build artifacts that I don't need to search), and having matches be greedy is not desirable. Also, command-T starts getting slow if CommanTMaxFiles is set over 20,000 files (I set it to 100,000 and rather extensive wildignore filter which helps but the initial scan is then much slower).

    Overall very useful plugin functionality, but I'm wondering if it would benefit from even more parts written in C?

  4. Greg Hurrell

    However, because of this way of matching I usually get things that I don't want as top hit even when I type full file name.

    You're using it wrong. On a large project you should be typing some characters from the earlier components of the path, not just in the filename. This will narrow down the search sooner more quickly and allow you to zero in on the file you want in fewer key strokes.

    eg. given file foo/bar/baz/bing/bong, an ideal search would be "fbbbb" rather than "bong", because it will help you zero in on the bong that you really want to open, and not some other bong in a different subdirectory elsewhere in the project.

  5. anonymous

    Yes, but that does not work because the files are in the same path and have same file part names: 

    ./a/b/c/d/e/f/TestResult.js
./a/b/c/d/e/f/TestResultEditor.js
./a/b/c/d/e/f/TestResultEditorView.js

    etc. and I want say TestResultEditor one. But it's not on top no matter what I type.

    Also, one of the compelling reasons to use Command-T is exactly that I don't have to remember which path the file is in. Trust me when you work on a project of this complexity and size, it becomes rather hard to know which path the file is, but I often know the file name.

  6. Greg Hurrell

    The entire design of the plug-in is predicated on the fact that you know where the stuff you're looking for is.

    When I wrote it, there were already various plug-ins out there that do exactly what you describe (ie. "file-centric" opening of files). The whole reason I wrote Command-T was that I wasn't satisified with this approach and I wanted a way to quickly open files using a "path-centric" mentality.

Reply

This topic is now closed.

topic index