Skip to content
Commits on May 22, 2016
Commits on May 17, 2016
  1. doc: Update docs for 4.0 release

    committed May 16, 2016
  2. Merge branch 'next'

    Going to cut a release soon, so time to update master.
    
    * next:
      Fix typo
      Show a warning when hitting g:CommandTMaxFiles limit
      Bump default g:CommandTMaxFiles up to 100,000 from 30,000
      vim: use base wildignore in Watchman scanner if necessary
      Replace g:CommandTFilterRegex with inference
      Make it possible to opt out of wildignore-based filtering
      vim: try to fix up wildignore documentation
      Add g:CommandTFilterRegex
      Hack fix for encoding issue
      Fix inability to type | and ^ at prompt
    committed May 16, 2016
  3. Fix typo

    committed May 16, 2016
  4. Show a warning when hitting g:CommandTMaxFiles limit

    Looks something like this:
    
    ```
    Warning: maximum file limit reached
    
    Increase it by setting a higher value in $MYVIMRC; eg:
      let g:CommandTMaxFiles=20
    Or suppress this warning by setting:
      let g:CommantTSuppressMaxFilesWarning=1
    For best performance, consider using a fast scanner; see:
      :help g:CommandTFileScanner
    
    Press ENTER to continue.
    ```
    
    Closes: #218
    committed May 16, 2016
  5. Bump default g:CommandTMaxFiles up to 100,000 from 30,000

    I am about to make hitting the file limit a whole lot more intrusive, so let's
    back the limit off a little bit. It should be ok to do this because:
    
    - Performance-sensitive users are probably already using a fast scanner, like
      the "watchman" scanner.
    - Computers are faster now than when I first implemented `g:CommandTMaxFiles`
      (March 2010), and when I last bumped the limit (April 2013).
    - For the slower scanners, we now have a progress indicator, which means that
      people get some visual feedback when something takes a long time.
    
    See: #218
    committed May 16, 2016
Commits on May 15, 2016
  1. Merge branch 'watchman-filtering' into next

    * watchman-filtering:
      Replace g:CommandTFilterRegex with inference
      Make it possible to opt out of wildignore-based filtering
      vim: try to fix up wildignore documentation
      Add g:CommandTFilterRegex
    committed May 15, 2016
  2. Replace g:CommandTFilterRegex with inference

    Crude and simple; definitely won't handle all cases, but let's start with
    something basic and only add complexity once it's clear that it's needed.
    
    Closes: #215
    committed May 15, 2016
Commits on May 14, 2016
  1. vim: try to fix up wildignore documentation

    Synthesizing the information from:
    
      wincent/wincent@b7c2f75
    
    We basically have:
    
      Wildignore      file      file        dir       dir         dir + file
      Pattern         "foo"     "sub/foo"   "foo"     "sub/foo"   "sub/foo/other"
      ---------------------------------------------------------------------------
      foo             match     match       miss      miss        miss
      foo/            miss      miss        miss      miss        miss
      foo/*           miss      miss        miss      miss        miss
      */foo           match     match       match     match       match
      */foo/          miss      miss        match     miss        miss
      */foo/*         miss      miss        match     match       match
    
    Note: these refer to which items get filtered from the Command-T listing. The
    behavior for tab-completion is pretty similar, but not identical.
    
    In practice, you want:
    
    - "foo" to ignore files named "foo".
    - "*.foo" to ignore files with an extension.
    " "*/foo" to ignore directories and all files in their subtrees, recursively.
    
    Note:
    
    - "*/foo" matches files and directories named "foo" plus their entire subtrees.
    committed May 13, 2016
Commits on May 12, 2016
  1. Add g:CommandTFilterRegex

    Possible fix for: #215
    committed May 11, 2016
Commits on Mar 29, 2016
  1. Hack fix for encoding issue

    I've found a directory that contains some files in it that cause the
    match window to blow up due to non-ASCII characters in their paths.
    
    They are showing up as "ASCII-8BIT" (ie. binary) but only when using the
    "watchman" and "ruby" scanners. The "git" and "find" scanners are fine,
    and notably the string encoding is "UTF-8" in that case.
    `g:CommandTEncoding` doesn't help.
    
    This is a temp fix to make it work, but I am pretty sure there are
    better places to put this. I feel bad about mutating the `match` strings
    like this. I could perhaps do it in the controller before passing to the
    match window. Better still would be to do it when it comes out of the
    scanner, although that could incur a speed hit for large hierarchies
    (because it would occur on the full set of possible paths, not the
    narrowed-down list).
    
    Other "fixes" that I tested that worked:
    
    - Dropping the `u` modifier on the regex.
    - Switching back to `chars` instead of `scan(/./mu)` (ie. pre-14fb52d19
      state).
    
    Stuff I tried that didn't work:
    
    - Switching to `\p{Any}` instead of `.` (both with and without the `u`
    modifier).
    committed Mar 28, 2016
Commits on Mar 16, 2016
Commits on Mar 12, 2016
  1. Use `findfile` in `HelpScanner`

    This enables us to get rid of some manual `#split`-ing and string
    concatenation.
    committed Mar 12, 2016
  2. Update specs

    committed Mar 12, 2016
Commits on Mar 10, 2016
  1. Add (inactive) debug code

    To enable: `ruby extconf.rb` (one-time only), then `DEBUG=1 make`
    whenever you want a debug build.
    committed Mar 10, 2016
Commits on Mar 9, 2016
  1. Fix non-recursive match scoring

    Using the test case and logging code from:
    
    #209
    
    I was able to spot that we had a bug in our match scoring in the
    `!m->recurse` case. Witness these memoized results:
    
           a       p       p       a       p       p       i       n       d
    a:  0.0684     -       -       -       -       -       -       -       -
    p:     -    0.1368     -       -       -       -       -       -       -
    p:     -       -    0.2051     -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    v:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -       -       -       -
    e:     -       -       -       -       -       -       -       -       -
    w:     -       -       -       -       -       -       -       -       -
    s:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    a:     -       -       -    0.2667     -       -       -       -       -
    p:     -       -       -       -    0.3350     -       -       -       -
    i:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    d:     -       -       -       -       -       -       -       -       -
    o:     -       -       -       -       -       -       -       -       -
    c:     -       -       -       -       -       -       -       -       -
    s:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    p:     -       -       -       -       -    0.3966     -       -       -
    a:     -       -       -       -       -       -       -       -       -
    g:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -    0.4137     -       -
    n:     -       -       -       -       -       -       -       -       -
    a:     -       -       -       -       -       -       -       -       -
    t:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -    0.4265     -       -
    o:     -       -       -       -       -       -       -       -       -
    n:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    _:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -    0.4812     -       -
    n:     -       -       -       -       -       -       -    0.5496     -
    d:     -       -       -       -       -       -       -       -    0.6179
    e:     -       -       -       -       -       -       -       -       -
    x:     -       -       -       -       -       -       -       -       -
    .:     -       -       -       -       -       -       -       -       -
    m:     -       -       -       -       -       -       -       -       -
    d:     -       -       -       -       -       -       -       -       -
    Final score: 0.617949
    
    Note the repeated matches in the "i" column, because after a match we
    were failing to break out of the inner `for` loop, meaning that we did
    not advance the needle pointer, `j`. Also, note that because we add to
    the match via `score += ...`, in these cases where we match the same
    needle character multiple times, we unfairly bump the score for each
    duplicate match as well, cumulatively.
    
    Interestingly, it's possible that this might improve search result
    quality, by boosting results that can match in multiple ways. Still, I'm
    fixing it in this commit for sanity reasons, so that our greedy
    algorithm behaves the way it says on the tin. It's not the default
    search mode in Command-T, and it is only enabled for people who want the
    extra speed (see below, tests run with `RECURSE=0`), so I think this is
    the right choice:
    
      Summary of cpu time and (wall-clock time):
                          best    avg      sd     +/-      p     (best)    (avg)      (sd)     +/-     p
           pathological 0.84000 0.91150 0.10608 [-7.4%]  0.005 (0.82952) (0.91382) (0.10469) [-7.2%] 0.005
              command-t 1.25000 1.33800 0.15181 [-1.4%]        (1.25809) (1.34222) (0.15379) [-1.4%]  0.05
      chromium (subset) 4.09000 4.67450 0.21238 [-5.0%]  0.005 (0.80025) (0.90810) (0.13991) [+1.4%]
       chromium (whole) 5.59000 5.81300 0.18453 [-9.5%] 0.0005 (0.76136) (0.91844) (0.17272) [-3.1%]
             big (400k) 8.74000 9.16200 0.29683 [-6.3%] 0.0005 (1.23149) (1.38036) (0.10847) [-6.5%]  0.05
    
    Corrected, our scoring matrix looks like this:
    
           a       p       p       a       p       p       i       n       d
    a:  0.0684     -       -       -       -       -       -       -       -
    p:     -    0.1368     -       -       -       -       -       -       -
    p:     -       -    0.2051     -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    v:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -       -       -       -
    e:     -       -       -       -       -       -       -       -       -
    w:     -       -       -       -       -       -       -       -       -
    s:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    a:     -       -       -    0.2667     -       -       -       -       -
    p:     -       -       -       -    0.3350     -       -       -       -
    i:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    d:     -       -       -       -       -       -       -       -       -
    o:     -       -       -       -       -       -       -       -       -
    c:     -       -       -       -       -       -       -       -       -
    s:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    p:     -       -       -       -       -    0.3966     -       -       -
    a:     -       -       -       -       -       -       -       -       -
    g:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -    0.4137     -       -
    n:     -       -       -       -       -       -       -    0.4821     -
    a:     -       -       -       -       -       -       -       -       -
    t:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -       -       -       -
    o:     -       -       -       -       -       -       -       -       -
    n:     -       -       -       -       -       -       -       -       -
    /:     -       -       -       -       -       -       -       -       -
    _:     -       -       -       -       -       -       -       -       -
    i:     -       -       -       -       -       -       -       -       -
    n:     -       -       -       -       -       -       -       -       -
    d:     -       -       -       -       -       -       -       -    0.4872
    e:     -       -       -       -       -       -       -       -       -
    x:     -       -       -       -       -       -       -       -       -
    .:     -       -       -       -       -       -       -       -       -
    m:     -       -       -       -       -       -       -       -       -
    d:     -       -       -       -       -       -       -       -       -
    Final score: 0.487179
    
    Note the lower score, now that the artificial boost is removed.
    
    This is a powerful testament to the usefulness of visual representations
    of data structures facilitating analysis of an algorithm and detecting
    anomalies in an implementation. Yay.
    
    Next up, will try to fix some similar craziness revealed for the
    recursive case.
    committed Mar 9, 2016
  2. De-dupe history entries

    History entries may differ only by insignificant trailing or leading
    whitespace (especially because we end up creating a history entry with
    a trailing space every time we accept and use a selection from the
    history finder) so strip it off and `#uniq`.
    committed Mar 9, 2016
  3. Don't set 'updatetime' and autocmd if g:CommandTInputDebounce is 0

    Even though I can't repro #208, this is probably the right thing to do,
    and I believe it should fix it.
    
    Closes: #208
    committed Mar 9, 2016
Commits on Mar 8, 2016
  1. Kill off trailer comments

    I've done these for years now as a readability aid, but they are a
    liability give my love of copy-pasta coding; they're just another thing
    for me to forget to update. Additionally, my classes should be simple
    enough that they aren't big enough to warrant this kind of "navigational
    aid".
    committed Mar 8, 2016
Commits on Mar 5, 2016
  1. Extract ProgressReporter class

    Alleviate one of the concerns of the `Scanner` class.
    committed Mar 5, 2016
  2. Switch to time-based progress reports

    These are more consistent, so lead to a better UX.
    
    I'm going to extract this out to another class though, as these instance
    variables don't really have any place in the scanner.
    committed Mar 5, 2016
  3. Add progress animation fanciness

    I don't plan on keeping this, but committing it anyway to show the idea.
    Basically we don't want to thrash the UI when we're trying to scan, so
    we slow down our updates as the result set gets bigger.
    
    The UX isn't great though because it looks like Command-T is slowing
    down, even though it isn't. Also, our silly spinner animation goes from
    being too fast to being pretty slow.
    
    I'm going to change this to be constant speed based on a time heuristic.
    committed Mar 5, 2016
  4. Let "find" scanner really report progress

    `#readlines` reads the whole output into memory and then returns an
    array, meaning we don't print any progress and then all of a sudden at
    the end we print it all.
    
    `#each_line` on the other hand calls our block as we go, which is what
    we want.
    
    I'm coding without internet access right now, though, so I am not sure
    whether `IO#each_line` is available in all the versions of Ruby that
    Command-T currently supports. I will check it out later and may have to
    add a fallback.
    committed Mar 5, 2016
  5. Add primitive first cut at progress reports

    This is a bit ugly because scanners don't know about the prompt, only
    the controller has a reference to it. We could have passed a reference
    to through the matcher to the scanner from the controller, but that
    would have been ugly. Ditto if we'd threaded through a callback. So,
    instead we opt to just update from the scanner and teach the controller
    to mediate by updating the prompt after the scanner has done its thing.
    
    This is ugly, but it's less ugly than the alternatives.
    
    I might want to back off the rate here later on, especially for large
    sets.
    
    Doesn't work so well when the find scanner is chewing through a big
    result set. I am suspicious of some major buffering going on in
    `#readlines` there.
    committed Mar 5, 2016
  6. Apply a minor consistency fix

    Make sure `calculate_match` behaves the same as `recursive_match` in the
    presence of `never_show_dot_files`.
    committed Mar 4, 2016
  7. Print real time delta in benchmarks

    We were repeating the total (CPU) time instead by accident. #copypasta
    
    Should be performance-neutral, but my stats claim otherwise:
    
    Summary of cpu time and (wall-clock time):
                        best      avg      sd     +/-     p     (best)    (avg)      (sd)     +/-   p
         pathological  1.04000  1.12000 0.10668 [+0.6%]       (1.04627) (1.11970) (0.10649) [+0.4%]
            command-t  1.29000  1.39100 0.11304 [-1.0%]       (1.30171) (1.39203) (0.11160) [-1.1%]
    chromium (subset)  5.31000  5.67300 0.28203 [+0.4%]       (0.94023) (0.99075) (0.04510) [-1.8%]
     chromium (whole)  7.13000  7.37300 0.09629 [+1.6%] 0.005 (1.00199) (1.07074) (0.04674) [-1.8%]
           big (400k) 10.99000 11.19700 0.12341 [+1.0%] 0.025 (1.51937) (1.64361) (0.06523) [-0.9%]
    
    I'm going to chalk that one up to random fluctuation.
    committed Mar 4, 2016
  8. Handle empty haystacks

    Unlikely to (should never) occur in practice, but this is a small
    simplification to the code.
    committed Mar 4, 2016
Commits on Mar 4, 2016
  1. Improve a comment

    committed Mar 4, 2016
  2. Clean up bitmask code a bit

    Instead of storing bitmasks in a separate array, pack them in the
    `match_t` struct. Shouldn't have much effect on perf. Maybe, you could
    make an argument for avoiding the allocation being a tiny advantage
    (almost certainly not measurable), but this might have better cache
    locality.
    
    I have no idea if my fancy Wicoxon Signed Rank test code is working or
    not, but it claims a likely significant reduction for the smaller data
    sets. I guess that makes sense, because there the allocation could
    actually form a measurable portion of the time.
    
    Summary of cpu time and (wall-clock time):
                        best      avg      sd     +/-      p     (best)    (avg)      (sd)     +/-      p
         pathological  1.04000  1.13400 0.04188 [-3.5%]  0.005 (1.04919) (1.13646) (0.04132) [-3.5%]  0.005
            command-t  1.34000  1.39500 0.04642 [-4.7%] 0.0005 (1.33263) (1.39542) (0.04737) [-4.7%] 0.0005
    chromium (subset)  5.02000  5.27400 0.11386 [-0.3%]        (1.13320) (1.20853) (0.03869) [-0.3%]
     chromium (whole)  6.80000  7.03350 0.08326 [-0.2%]        (1.20307) (1.28563) (0.04056) [-0.2%]
           big (400k) 10.64000 10.84500 0.18416 [-0.4%]        (1.82905) (1.94810) (0.08647) [-0.4%]
    committed Mar 1, 2016
Commits on Mar 3, 2016
  1. Update README

    To refer to some newly added capabilities (and
    others not so new), and to elevate speed as the
    primary design goal.
    committed Mar 3, 2016
  2. Actually add <Plug>(CommandTSearch)

    Again, stop overpromising in HISTORY and underdelivering.
    committed Mar 3, 2016
Something went wrong with that request. Please try again.