Giters

ggandor / leap.nvim

Neovim's answer to the mouse 🦘

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Defaults: bidirectional leap for Normal mode (use `<Plug>(leap)`)

ggandor opened this issue · comments

commented

Pro

  • only one key used, comfort
  • prioritizing the current line did the trick, and IMO made the whole concept work; smart autojump (the default) is not fully deterministic anyway, even if the search is directional, you might have to use a label for the first target too
  • we lose only 1 bit of information (versus 8-10 in the pattern itself)
  • in Normal mode, as opposed to Visual and O-p mode, we're not interested in the target in relation to our current position, we just want to jump there

Con

  • inconsistency between Normal and Visual/O-p mode (though there is a fundamental difference, see above)
  • traversal (which implies directionality) is useful for "f/t" mode (s{char}<enter><enter>...) (related: #210)

An old discussion in the Sneak repo: justinmk/vim-sneak#62

Noise means ... there are twice as many target labels on average

True, bidirectional mode means more visual noise.

label-mode will invoke twice as often (fewer opportunities to jump to a single match and skip label-mode)

Right... (but as mentioned above, it's still only 1 bit of information we're losing, the pattern itself contains a lot more)

half as many labels available in the direction you want to go, which means more steps

With smart autojump (using an extended label set on demand), it's very rare to have additional steps, group switch is a truly exceptional case.

Also: which direction should bi-directional search go if all matches are off-screen?

Fortunately, not a problem here. Use /? for their intended purpose, that is, searching in the unknown, and Leap for jumping to on-screen positions.

You pay these costs every single time all for the convenience of occasionally being able to search backwards.

Yeah, but "occasionally" = 50%.

commented

Yes. yes, and yes please. I've been craving this for a while.

commented

prioritizing the current line did the trick, and IMO made the whole concept work; smart autojump (the default) is not fully deterministic anyway, even if the search is

What if always smart jump forward, and also put labels above?

commented

@ggandor Is there a way to test these new changes?