Open wincent opened 1 year ago
đź’ˇ Absolute path search
đź’ˇ Absolute path search
@Takuzen can you elaborate a bit on how you'd want such a thing to work?
@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.
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.
@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).
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.
Thanks for the report @jaapie — split off into a separate issue here:
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):Feature requests
For parity with Ruby version
[^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.