You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Feature request #1516: Match against filename only

Kind feature request
Product Command-T
When Created , updated
Status closed
Reporter Greg Hurrell
Tags no tags

Description

From a user email:

My problem is , when my project directory and subdirectory is deep,sometimes even I typed all the filename ,I also can't get to the right one. I guess it is the reason of match method. now command-T match not only filename,but also path,so when directory is deep and deep,the word I typed is matched to the path but not filename, I think someone else maybe also have this question.And I know the match method of command-T is like LustyExplorer,but I think it is not same. Because LustyExplorer only match the filename or subdirectory in current path, and our command-T match all the filename.

So , I suggest command-T to match only filename, but not match path ,just like lookupfile.vim and what do u think about this ?

Comments

  1. Greg Hurrell

    Searching using the entire path name was actually a very conscious, intentional design decision. Rather than typing characters from the filename, I actually want my users to be thinking in terms of the path to the file and including letters from the path. It's a different mindset.

    For example, just say you want to open this file:

    • app/controllers/admin/issues_controller.rb

    I want you to type something like:

    • acai (ie. "a" for app, "c" for controller, "a" for admin, "i" for issues)

    Rather than something like:

    • issues or isscon

    Obviously on small projects you can take either approach and you'll very quickly zone in on the file you're looking for. But on larger projects where there might be a lot of files which have the string "issues" in the filenames, you'll find that including letters from the preceding paths will actually help you narrow things down a lot quicker. The classic example here is a Rails application which will have a bunch of paths like:

    • app/controllers/issues_controller.rb
    • app/controllers/admin/issues_controller.rb
    • app/helpers/issues_helper.rb
    • app/models/issue.rb
    • app/views/issues/index.html.haml (and many other templates)
    • spec/controllers/issues_controller_spec.rb(and many other specs)

    On a project like that typing "issues" is only going to produce a long list of files which all have similar bases and you'll end up having to scan them visually, which is slow. If you get in the habit of including some characters from the upper path components then you'll find that the list narrows down much more quickly, and to something much shorter.

    This is what I mean by taking on a different "mindset"; the bigger the project is, the more you need to think in terms of where the file is rather than what it is called. If you can do this you'll be able to find stuff so much more quickly.

    And in the few weeks I've been using the plug-in I have gotten a "feeling" for how much information I'm going to have to type in order to get to the file I want, depending on the number of files in the project and the amount of similarity between their paths. On a small project if I am looking for that issues_controller.rb file I might be able to get away with isscon or coniss or even acai like I suggested above; and on bigger projects I might end up typing something like appconiss or appadminisscon etc. After working in a project for a very short while you get a feel for how verbose you need to be.

    So that's why it works the way it does, because if you merely want to match against characters in the filename only, you can use other plug-ins which already work that way. And I wouldn't have bothered writing a new plug-in if all I wanted was to copy the behavior of an existing one.

    For example, to set up FuzzyFinder to behave like that you can get it to automatically prefix **/ to all search strings and it works quite nicely. See this page for info on how to do that (basically boils down to doing something like noremap <silent><Leader>e :FuzzyFinderFile **/<CR>).

    So, sorry. I don't think I would want to change that particular aspect of the behavior, even as an option. About the only thing I might consider changing is tweaking the scoring algorithm to give slightly more weight to letters that match the filename segment, but it might be a bit fiddly as in that case I'd actually have to run my searches from right-to-left rather than left-to-right to do it in any sort of efficient manner.

  2. Greg Hurrell

    Status changed:

    • From: new
    • To: closed
  3. Greg Hurrell

    In the interests of keeping all related discussion in one place, just got tipped off to this commit in an email:

    I find your Command-T plugin really useful, great job! But after using it for few days I found the default behavior not perfect. Command-T is searching for entered characters in whole file path (relative to pwd) but in most cases you know the filename and it's easier to enter just few characters of filename. In my opinion better would be to search in file names without path by default, and use filename with path if entered search term contains "/". This way we cover both use cases, with default one being similar to Textmate's Go-To-File or Netbeans' OpenFileFast.

    Here's my reply:

    This has been requested once before:

    https://wincent.dev/issues/1516

    Take a look at that ticket for a fairly detailed explanation of the reason why it works the way it does. The short version is:

    • philosophically, the whole design of the plug-in revolves around being in a "mind set" which is path-centric, not filename-centric
    • if you prefer to think in terms of filenames, there are already a number of alternative options for VIM which provide very good filename-centric navigation; there really would have been no justification for writing the plug-in in the first place if it was just to add another filename-centric way of opening files

    While adding the optional behavior you're talking about might be good for users like you, it would actually undermine the design goals of the plug-in despite being "optional", because it would oblige people to type additional slash characters in order to use the plug-in in the path-centric way which was intended.

Add a comment

Comments are now closed for this issue.

Menu