💡 Ideas for improvements — compendium issue

[wincent]

I just declared The Great Reset™️ by closing all open PRs and issues which predate the 6.x release (more info on the release here) because a lot of them are specifically targeted at the old implementation, and 6.x is a complete rewrite.

Nevertheless, there were some neat ideas in there that I can see being worth resurrecting and working on in 6.x+/main in the future, so I just wanted to gather some of them together here — this is by no means a complete listing, but it includes many of the ones that immediately resonated with me[^fair] (in no particular order):

• https://github.com/wincent/command-t/issues/286
• https://github.com/wincent/command-t/issues/282
• https://github.com/wincent/command-t/issues/278
• https://github.com/wincent/command-t/issues/277
• https://github.com/wincent/command-t/issues/276 (sadly, I don't think this one is viable, due to the immense storage requirements[^stack], but I wish it was)
• https://github.com/wincent/command-t/issues/238 (we don't have caching yet in 6.x, but we might add it)
• https://github.com/wincent/command-t/issues/248 (we can already do this for command-based scanners, but I'd like to allow arbitrary Lua functions)
• https://github.com/wincent/command-t/issues/93 (in an ideal world, we instead make scanning so fast that you never need/want to cancel it; but in the real world, this seems like a nice-to-have)

Feature requests

For parity with Ruby version

• https://github.com/wincent/command-t/issues/416

[^fair]: To be fair, I created many of these 🤣. [^stack]: The size of the memoization data structure is kind of "hidden" by the fact that it is stack-allocated on every key-press, so there's no malloc()/free() in there to draw attention to how much space it actually needs — but it can be rather a lot when the corpus of haystacks is large.

[Takuzen]

💡 Absolute path search

[wincent]

💡 Absolute path search

@Takuzen can you elaborate a bit on how you'd want such a thing to work?

[Takuzen]

@wincent Sorry for the lack of words. I only jotted down my instant idea. With the initial configuration, I couldn't type absolute path or any path pointing to files in upper directories. I remember you have mentioned that all of the file scanners work in this way — they recursively search from the current directory and find whatever you have in there before and I have not elaborated the whole design how we can achieve this functionality. I will come update when I get more details.

[rieje]

Is it possible to use existing buffer as the "previewer"? Basically, how the Swiper plugin for Emacs works. It is better in the following ways:

• Much less visual noise. Basically, it's just opening the a mini buffer on the bottom for the results and the rest of the screen is an existing buffer that shows the previews. This means what you see as preview is what you will get, retaining syntax highlighting, including the results.

• The regex-matched portion is highlighted on the preview. This just feels intuitive and in line with incremental searches in Vim.

Both are important to provide context and is a true preview of the buffer as opposed to merely text extracted from the buffer. I am not aware of any fuzzy find plugins in Vim that do not rely on a "fake preview". IMO the Swiper plugin is the most elegant solution and is intuitive.

[wincent]

@rieje Have you tried nvim-telescope? That has a pretty good preview functionality (honestly, better than Command-T is ever likely to have, which is why I bring it up... Command-T will probably continue to prioritize speed over all else as its main differentiator, so features like preview are pretty low priority as then entire into conflict with the whole "as fast as possible" goal).

[jaapie]

When multiple files are opened when invoking nvim from the command line, :CommandTBuffer doesn't know about all the buffers. I am not sure if that is by design or not. This makes switching buffers with command-t impossible until all the buffers are cycled through with :bnext or similar. Once that is done, :CommandTBuffer knows about all the buffers.

[wincent]

Thanks for the report @jaapie — split off into a separate issue here:

• https://github.com/wincent/command-t/issues/418