justinmk
<tab> in label-mode should un-highlight skipped matches
I think the way leap.nvim does this is much nicer where the cursor never moves from its initial position (but still un-highlights the skipped matches)
Not sure yet how much of a headache that would be to implement in vim-sneak
Do you prefer the way the cursor moves on Tab?
Either way I may be interested in tackling this at some point
@tuurep I never thought about moving the cursor in the first place, as I haven't even noticed this behavior in Sneak until now.
Note that if <tab> does not actually move the cursor, it would be possible to use an extended label set for all match groups beyond the first one, which is IMO a no-brainer (including 20-30 more targets in the second group, versus making the 23rd-or-so target directly reachable with <tab>).
Related: #304, but the above itself is not "smart" or non-deterministic behavior at all.
Ah, didn't realize that might be key regards that. TBH I've settled for quite a small set of labels, to avoid any uppercase characters and having to use a modifier key, finding the <Tab> (or leap <Space>) preferable to a hard-to-press label. That's at the cost of not seeing the label in advance though.
Even without that I think <Tab> not moving the cursor is better for these reasons:
- In operator-pending, more clearly shows the span you're operating on
- (actually the first match seems complicated here :( )
- When reversing, the idea is that you've overshot and want to go back. But when the cursor moves, you reverse the order of the previous set of labels, adding for maximum overhead.
much nicer where the cursor never moves from its initial position (but still un-highlights the skipped matches)
If the un-highlight works then the cursor as a visual-aid is less important. But there is still a cost, which is that if sneak is dismissed, then the cursor placement is different than what was indicated. A key feature is that you can dismiss sneak at any time painlessly.
Not sure yet how much of a headache that would be to implement in vim-sneak
Yes, a complicated implementation would be a dealbreaker. A simple implementation is worth considering.
TBH I've settled for quite a small set of labels ... finding the
<Tab>(or leap<Space>) preferable to a hard-to-press label.
Yes, it's an intentional decision of vim-sneak to not do the "extended labels" thing, it presents the user with a "puzzle" which raises the question of why not use / or other navigation mechanisms instead. <Tab> is the escape-hatch for rare cases or where you might want dot-repeat.
it's an intentional decision of vim-sneak to not do the "extended labels" thing ... <Tab> is the escape-hatch for rare cases
Still I don't get it why we need to intentionally limit the efficiency of the escape hatch, when it could decrease the steps (inputs, checkpoints) needed for a jump.
Provided that <Tab> does not move the cursor (abc are "safe" labels - no "fallthrough" expected):
>tab >tab
[abc][abc][abc]
----------
here we restrict ourselves unnecessarily, from the user's point
(already used Tab, no fallthrough) there is zero reason not to:
>tab >tab
[abc][abcdefghij][abcdefghij]
@tuurep 's remark about hard-to-press labels is orthogonal, in fact, the gain might be even more in his case (4-5 versus 15-20 comfortable lowercase letters).
If the un-highlight works then the cursor as a visual-aid is less important. But there is still a cost, which is that if sneak is dismissed, then the cursor placement is different than what was indicated.
Again, according to this proposal, the cursor does actually stay in place, <Tab> just cycles the highlighting, it's a different mental model. My educated guess is that you have a gut reaction against introducing state (which set of labels are "active"), but that doesn't complicate the implementation that much compared to the gain (and it's a net gain for users).
it presents the user with a "puzzle" which raises the question of why not use / or other navigation mechanisms instead
Arguments along this line ("Sneak is not for...") sound a tiny bit like a thought-terminating cliché to me (cf. "a text editor should not have a terminal...") :) You use labels because you don't want to compose multiple atomic motion commands, or press n 10 times, or play Scrabble with /, and then adjust the cursor.
Also I don't buy this reasoning, because Sneak vs / is already a "puzzle". / is not the "obvious" (reliable or really ergonomic) way to jump to arbitrary, distant positions in the window in the first place - it often works fine, but labels (even the limited set) might be better, it's a guesswork anyway. Extended labels would actually improve the situation IMO, since with one <Tab>, Sneak could reach practically any position, so there's even less place for "should I use /?" thoughts to occur. If you just lower the friction of the feature, what was considered an "escape hatch" might turn out to be a legit alternative.
Still I don't get it why we need to intentionally limit the efficiency of the escape hatch, when it could decrease the steps
"could" is the operative word, it means that a 1-char target may become a 2-char target, which means you never know, even if your actual desired target is within the first few matches.
Sneak vs
/is already a "puzzle".
All of the constraints in Sneak are intended to make it predictable, it doesn't change behavior depending on number of targets.
We're talking past each other. Here I'm not talking about "smart" mode (as in #304), I'm just saying that the label sequence should be [abc][abcdefghij][abcdefghij]... anyway, independently of the number of targets. The first set should always be "safe", but once the user has used <Tab>, there is no reason to use a limited set, since it is clear that they want to select a label.
"could" is the operative word
I meant "could (always) reduce if implemented in the above way" :)
The first set should always be "safe", but once the user has used
<Tab>, there is no reason to use a limited set
Oh, yes that makes sense. Only question then is how complicated is the logic.
Mainly I think <Tab> is not something that needs to be optimized because it is inherently a UI failure.
<Tab>is not something that needs to be optimized because it is inherently a UI failure
I see your point, but I can just repeat myself: a 2.5 multiplier is a pretty darn big difference.
Yeah ggandor I see your point, thanks for persisting on it though seems fairly painful 😄 I think, finally I agree with you.