Fzf: Maintain cursor position when deleting text

[gibfahn]

• [x] I have read through the manual page (man fzf)
• [x] I have the latest version of fzf
• [x] I have searched through the existing issues

Info

• OS
  
  
  
  • [x] Mac OS X
  
  
• Shell
  
  
  
  • [x] zsh
  
  

Problem / Steps to reproduce

It would be really nice if when you delete a character, fzf would keep the cursor on the same line (as it will always still be matched).

This would allow better use of fzf for browsing things like git history, before filtering.

For example:

1. I'm looking for a commit, I know it was near the 1.0.0 commit.
2. I open my interactive git log to search for it.
3. I type 1.0.0 to find the 1.0.0 commit.
4. I press Backspace to delete the 1.0.0, so I can see the surrounding commits.
5. Unfortunately fzf preserves the line I was on (i.e. 4th line down) rather than the text I was looking at (i.e. 100th row of text) so I can't achieve this feature.

Not sure if this should be the default or an option, maybe there are good uses for the default (like not wanting your cursor to get stuck all the way at the bottom).

See https://asciinema.org/a/304635 for a visual example (git li defined here):

[LuRsT]

Hi @gibfahn,

I think that feature sounds like something that would work well for this exact use case, but it doesn't really make sense for fzf in general. When you use backspace to delete the characters from 1.0.0, what you're doing is in fact re-searching for 1.0., not holding the line you were in to check around.

I'm struggling to figure out a way to achieve what you want (which I think makes sense for your use case) with fzf. But I don't think this is a feature to add to fzf.

PS: Nice gitconfig you got there!

[junegunn]

Thanks for the suggestion. I also think it can be a nice addition to fzf, but I probably won't try to implement the scheme anytime soon because it only makes sense in relatively rare use cases where --sort is disabled and it's really not trivial to get it right. There are surprisingly many things to consider UI-wise and performance-wise. Imagine there are tens of thousands of matches from several million items, your cursor in on the 500th page of the matches, and fzf is still asynchronously consuming new data. It may not get along well with some of the existing options such as --tac.

I may revisit this in the future but I'm going to close this for now.

[gibfahn]

Yep, totally makes sense, and if I could think of a way to do it outside fzf I would.

I guess the issue is that I (and I assume others) use fzf not just for searching, but as a general list browser that also has a search bar, which is why there end up being so many complicated feature requests 😁 .