leap.nvim icon indicating copy to clipboard operation
leap.nvim copied to clipboard

Take in 3+ characters instead of the default 2

Open kovasap opened this issue 3 years ago • 2 comments

Is there a way to configure this plugin to take in 3 or more characters after s? I often find that my files have many matches for two characters, and it's smoother for me to directly read the text at the place I want to go, as opposed to the arbitrary hint letters placed at each match by leap. The leap-added letters require me to (1) read the place I want to go, (2) type s{c1}{c2}, (3) read the place again to react to the leap-added character, (4) type the character. It seems smoother to instead (1) read the place I want to go, (2) type the characters there until my cursor gets there. The hint letters are still useful as an escape hatch in case the string i'm searching for is long and occurs many times in the file.

I realize I'm basically just describing search, but that involves extra keystrokes to exit the search, and doesn't have hint letters.

I'm still newish to this plugin, so maybe there is another option that reduces this friction (or i just need to get used to it).

kovasap avatar Aug 29 '22 18:08 kovasap

The very point of Leap (and Lightspeed) is that you don't have to pause and check the "result" of your actual input ("Am I already there? Should I type more characters?"), and don't have to make any decisions, because at every stage it's already determined what your next keypress should be. You always have to type two characters, and if there is a need for a 3rd one, you already know it after the first input (well, if you're not typing extremely fast).

require me to (1) read the place I want to go, (2) type s{c1}{c2}, (3) read the place again to react to the leap-added character

It's more like: (2) type s{c1} (3) while typing {c2}, with your eyes still on the target (assuming you're touch typing, as a Vim user), your brain is already processing {label}, if there is one (4) type {label}, and you're there

With the method you described ("native search on steroids"), you also have to "react" to something - whether you've arrived or not - but you can never know that beforehand, if focusing on the target, it's always a surprise. If there are labels, we also have to tell the plugin first that we've finished with the pattern (with e.g. enter), so that the labels can be assigned to the matches - another decision, another additional keypress. You can try Hop, if not convinced (there is a motion called HopPattern), and see how that works for you.

There is also Pounce, with an alternative solution: it uses fuzzy matching, and continuously relabels the matches as you type, according to some smart "black box" algorithm (it is even possible that a label suddenly disappears). That is - IMO - as confusing as it sounds, and this constant surprise factor undermines the whole thing, even if it works reasonably well most of the time. Additionally, the labels should all be uppercase characters, and the search can only be case-insensitive (so that the labels cannot conflict with the pattern inputs, and there's no need for accepting the pattern with enter first).

ggandor avatar Sep 02 '22 09:09 ggandor

This issue actually made me understand why this plugin does what it does. It is a really cool idea and I agree with what @ggandor says.

I think the big distinction is that you are already looking at the place you want to go, and in that case it is a LOT better than searching for the word.

AlexvZyl avatar Sep 06 '22 07:09 AlexvZyl