Use a menu rather than a buffer?

  1. Marcus

    I'm a recent convert from fuzzyfindertextmate (still using it for buffers actually, but command-t for files). I'm loving command-t so far, especially the ease of installation and the fact that it's actively maintained.

    I was wondering if there was a reason behind using a new buffer for results rather than the type of menu fuzzyfinder uses that overlays existing buffers? I find it a bit jarring to have the whole screen shift around as results are shown and filtered. Perhaps it could be a preference to have results come up in a menu?

    Again, thanks for your work on command-t, it's great.

  2. Greg Hurrell

    I don't actually know how FuzzyFinder is doing that overlay thing. I have noticed, however, that it seems to be quite slow and flakey, so I am not sure if it is exactly the model to emulate. I would be interested, however, in knowing exactly how it does it.

    The buffer trick that Command-T uses is modelled on the same technique used in Lusty Explorer. As I note in the readme, this is the first Vim plug-in I've made, so I studied Lusty Explorer for tips on how to get a lot of basic stuff done, as it is a good example of a fairly large and complex plug-in written in Ruby.

  3. Marcus

    Thanks for your reply. I'll look at FuzzyFinder and see how he does the overlay. I haven't found it to be flakey, but it does feel slower. I am not sure if that's a product of the menu style being used to show results or something else going on.

  4. David Lee

    It might just be that fuzzyfinder_textmate is slow at retrieving the results. Rendering a menu might be just as fast as using a buffer.

  5. anonymous

    Any updates? Would be really glad to have that.

  6. Greg Hurrell

    The current buffer-based solution works well for me, and represents a fairly large part of the logic in the code base, so I haven't spent any time looking at alternative implementations.

    If somebody is sufficiently interested in the idea, it would be up to him or her to whip it up. I'd be happy to look at patches, although any patch that I would apply would probably have to support both methods, keeping the buffer-based method as the default, as the user base is probably pretty used to it by now.

    One point of the original poster that I never addressed was about the current implementation being "pretty jarring" because it cause so many screen elements to move around. My personal take on this is that you can make that problem goes away entirely with a couple of settings in your ~/.vimrc: 

    let g:CommandTMatchWindowReverse   = 1
let g:CommandTMaxHeight            = 10

    Those limit the match listing to a maximum of 10 rows, and reverse the order of it so the best match is always closest to the bottom (ie. immediately next to the prompt). Other variations are possible, but I think limiting the maximum height is the key one.

Reply

This topic is now closed.

topic index