extended labels ("smart label mode") about vim-sneak HOT 4 CLOSED

If I'm not mistaken, it's basically just adding a line like

label-list = ((#matches > #safe-list + 1) && (#unsafe-list > 0)) ? unsafe-list : safe-list

before assigning the labels, plus adding a similar check to the condition expression when deciding about jumping to the first match. The rest is details. This is why I dared to raise this, the implementation is more or less trivial.

I suspect that when there are numerous matches, "efficiency" is a lost cause

50 instead of 20 is considerable difference, we're talking about a 150% increase. This also adds to the power of tab itself - with only one switch, more than a hundred targets can be covered.

from vim-sneak.

Thanks for the request, but this is intentionally out of scope since day 1. https://github.com/justinmk/vim-sneak/issues?q=label%3Awontfix+is%3Aclosed

EasyMotion and other jump plugins try to do everything, and it becomes feature creep:

• as you mentioned, "a certain degree of non-determinism": sneak is intended to be very predictable
• <tab> can already be used to label the next 20 matches
• for more complex cases, it makes more sense to use /

from vim-sneak.

Thanks for the response! First of all: I can totally relate to your sentiments about feature creep, minimalism and consistency, this high conceptual integrity is what I love about Sneak. But in this case the counter-arguments are not terribly convincing IMO, so I just leave my 2 cents here.

I think label mode already breaks with the original idea of Sneak being the "missing motion" halfway between f and /. / helps nothing if there are lots of identical words. This is the very point of using labels: you don't want to guess how "complex" a case is, ideally you just want to jump to a target you see, without scanning the window content first. With a labeling plugin available, you don't have to abuse / anymore to move around the screen, you can use it for it's intended purpose, that is, finding matches.

And I'd say this smart mode is the typical example of a high-leverage feature. There's nothing complicated about it. Only a few lines of code should be added, and exposing a g: var, which is optional to use. Instead of flags, the state of the two lists implicitly affects the behavior. Nothing should change about the default experience. On the other hand, one could reach 2-3x more targets with ease if they opt for it. It wouldn't just provide a choice between "Sneak or EasyMotion", but anything between the two.

I heavily agree with the importance of being as predictable as possible, but no search-based motion can be 100% predictable in the first place, since they presuppose contextual knowledge. There is always the possibility of an in-between match you might miss. This mode doesn't make matters noticeably worse, because as I said, it's rare that you want to target the first one among 20+ matches. And the gains are high, it will become easy to reach dozens of additional targets in exchange. Small optimizations like this are not unimportant, because you do these jumps hundreds of times a day. Switching with tab is awkward, especially in Sneak - you need to pause twice (or more) to process the visual feedback.

from vim-sneak.

There's nothing complicated about it. Only a few lines of code should be added, and exposing a g: var, which is optional to use. Instead of flags, the state of the two lists implicitly affects the behavior. Nothing should change about the default experience. On the other hand, one could reach 2-3x more targets with ease if they opt for it.

If that's true then I'm less strongly opposed, though it does increase the explanations needed in documentation.

But generally I suspect that when there are numerous matches, "efficiency" is a lost cause, so <tab> is fine as an escape-hatch. Eventually you run out of labels, even with "smart" mode.

from vim-sneak.