≡

wincent.dev

  • Products
  • Blog
  • Wiki
  • Issues
You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.
Home » Issues » Bug #1930

Bug #1930: command-t suddenly stopped indexing some files

Kind bug
Product Command-T
When Created 2011-11-30T09:19:43Z, updated 2011-12-01T09:16:30Z
Status closed
Reporter anonymous
Tags no tags

Description

Opening command-t and typing 'faqcontr' suddenly doesn't list the app/controllers/faqs_controller.rb like before

Instead it only shows the following three files:

test/functional/admin/faqs_controller_test.rb
test/functional/admin/faq_categories_controller_test.rb
test/functional/inquiries_controller_test.rb

It might be that I've mashed the wrong keys somehow during hard vim usage that somehow made command-t stop indexing some directories.

It doesn't help to restart vim. Haven't tried restarting the whole system.

Comments

  1. Greg Hurrell 2011-11-30T18:16:28Z

    Sounds like the number of files in your directory exceeds the g:CommandTMaxFiles setting (which defaults to 10,000). You can increase that.

    Alternatively, your Vim 'wildignore' setting might be excluding those files, if you've changed that recently (which I doubt).

    See the docs for more info.

  2. Greg Hurrell 2011-11-30T18:16:32Z

    Status changed:

    • From: new
    • To: closed
  3. anonymous 2011-12-01T05:19:35Z

    That seems to be the case. Is there some way to check how many files are indexed so you know when you need to consider updating wildignore or changing the max files setting?

  4. Greg Hurrell 2011-12-01T08:20:58Z

    You could get an approximate idea (ie. not taking into account ignored files) in the shell with:

    $ find . -type f | wc -l

    In general you can just up the limit until you notice some kind of performance degradation. On my machine, for example, I've upped it to 30,000 with no problems. This gives me considerable headroom in the largest project I'm currently working on (about 11k files).

  5. anonymous 2011-12-01T08:53:28Z

    Well that's gonna count files inside dot directories too right?

    I think command-t feels a little bit sluggish already with 10k files. But I'll try upping it to 20k and see what happens.

  6. anonymous 2011-12-01T08:59:47Z

    Well I remembered you can do it with find | grep -v '/\.' | wc -l

    And I upped the limit to 20k and yeah it's still really fast. I don't where I got it from that it sometimes feels a little bit sluggish.

  7. Greg Hurrell 2011-12-01T09:16:30Z

    In my experience the three things that can make it feel sluggish are:

    • opening it in a directory with a million files and the g:CommandTMaxFiles set too high
    • not having 'wildignore' appropriately set to ignore hierarchies that you're not interested in
    • having an ambiguous mapping that Vim has to wait for to disambiguate

    That last one is particularly subtle. In my case I had Command-T mapped to <Leader>t (ie. \t), and there was a noticeable delay every time I opened it, even though it was instant for colleagues who have identical machines to mine.

    Turned out that the Align.vim plug-in defined a bunch of other mappings that all began with <Leader>t, which meant that whenever Vim saw <Leader>t it had to pause for a second to see if I was going to continue typing one of the letters corresponding to those other mappings.

    In the end I got around it by preventing Align.vim from loading the file that sets up those conflicting mappings with a line like this in my ~/.vimrc:

    let g:loaded_AlignMapsPlugin = "v41"
Add a comment

Comments are now closed for this issue.

  • contact
  • legal

Menu

  • Blog
  • Wiki
  • Issues
  • Snippets