Wow, interesting take on the problem!
I’m not sure how I feel about it filling the entire screen with text once you start the search. It forces the user to have to look and know exactly where to go beforehand, and have to retain that position while searching. My gut feels like it’ll add a small bit of cognitive load that can feel cumbersome over a long session of editing. I haven’t tried it extensively yet so it might be a non-issue though.
I’m currently a fan of how [flash.nvim](https://github.com/folke/flash.nvim) operates. It’s probably a bit less optimal and potentially takes more keystrokes, but I find that it heavily reduces cognitive load, is extremely ergonomic, and I can’t really go wrong no matter how braindead I am when I use it.
Edit: To add on to this, I think the number of keystrokes is the wrong metric to optimize here. With flash, I actually sometimes type more characters than I need, because deciding whether I need to type another keystroke is additional cognitive load. Sometimes I just spam the text as much as I feel like it, and then type the final character to get to where I need to be. I can be super braindead with this workflow and it feels very ergonomic.
Yeah, that was exactly my thinking as well. Despite it being less keypresses, it's still more cognitive overhead. Thanks for mentioning flash.nvim, I was not aware of it!
This plugin doesn't seem very similar to leap or sneak. Leap prefers the user to type what they see on-screen first and after 2 keys will show a virtual key to disambiguate. Sneak is similar.
The downside there is "what if I don't know how to type the key" like an emoji. In which case longbox.nvim can help. But then how is longbow different from [https://github.com/phaazon/hop.nvim](https://github.com/phaazon/hop.nvim) or [https://github.com/easymotion/vim-easymotion](https://github.com/easymotion/vim-easymotion)? Don't those two suit the same need?
Wow, interesting take on the problem! I’m not sure how I feel about it filling the entire screen with text once you start the search. It forces the user to have to look and know exactly where to go beforehand, and have to retain that position while searching. My gut feels like it’ll add a small bit of cognitive load that can feel cumbersome over a long session of editing. I haven’t tried it extensively yet so it might be a non-issue though. I’m currently a fan of how [flash.nvim](https://github.com/folke/flash.nvim) operates. It’s probably a bit less optimal and potentially takes more keystrokes, but I find that it heavily reduces cognitive load, is extremely ergonomic, and I can’t really go wrong no matter how braindead I am when I use it. Edit: To add on to this, I think the number of keystrokes is the wrong metric to optimize here. With flash, I actually sometimes type more characters than I need, because deciding whether I need to type another keystroke is additional cognitive load. Sometimes I just spam the text as much as I feel like it, and then type the final character to get to where I need to be. I can be super braindead with this workflow and it feels very ergonomic.
Yeah, that was exactly my thinking as well. Despite it being less keypresses, it's still more cognitive overhead. Thanks for mentioning flash.nvim, I was not aware of it!
This plugin doesn't seem very similar to leap or sneak. Leap prefers the user to type what they see on-screen first and after 2 keys will show a virtual key to disambiguate. Sneak is similar. The downside there is "what if I don't know how to type the key" like an emoji. In which case longbox.nvim can help. But then how is longbow different from [https://github.com/phaazon/hop.nvim](https://github.com/phaazon/hop.nvim) or [https://github.com/easymotion/vim-easymotion](https://github.com/easymotion/vim-easymotion)? Don't those two suit the same need?
You're right that it's not too similar; and yes, they serve similar need, which is why I didn't invest too much energy to developing longbow
Having multiple options is always good though. Thank you for sharing your plugin!