bidirectional / "cloud" sneak

[justinmk]

You know you want it.

Yeah, I do.

[LFDM]

That would be most welcome!

[LFDM]

Any ideas how this could be implemented?
It's probably not so hard to program, but a challenge to think about what it should actually do.

• Should it work only for streaking or for sneaking too?
• Is there a difference when a bidirectional mode is invoked with s or S?
• What will , and ; do?

[justinmk]

As far as I can tell, bi-directional search is for people who don't want to think about the direction of their target, and/or they don't want to dedicate an extra key for "backwards" direction (eg, S). It's nice to be able to mash s and know that your target is going to appear, regardless of direction.

However, the problem with bi-directional is that it's going to put the user into streak-mode roughly twice as often, which IMO sucks. The point of vim-sneak is to get out of the way ASAP.

Should it work only for streaking or for sneaking too?

I don't think it would make sense for vanilla sneak, since the user still has to choose a direction anyways, even though both directions would be highlighted.

Is there a difference when a bidirectional mode is invoked with s or S?

AFAIK the point is to get rid of S. I haven't yet looked at haya14busa's easymotion implementation of bi-direction, though. Have you tried it?

What will , and ; do?

Good question. I think ; would always go "down" and , would always go "up".

Thanks for your thoughts.

[LFDM]

Looked at easymotion's implementation briefly, nothing unexpected there. Bidirectional mode searches into one direction, than into the other, and merges the results.

Agree that it makes only sense in streak mode, also agree on how , and ; should behave.

From a usability point of view, one of sneak's pros is that it provides a good target-label keymap by default. In most cases wherever I want to go to, is on the homerow.

Not sure how this would work out in bidirectional mode. Placing labels in circles? Prioritized by distance? (e.g. next hits are two lines up => target key a, three lines down => d, four lines up => f) Or is this already overcomplecting the problem?

[haya14busa]

From a usability point of view, one of sneak's pros is that it provides a good target-label keymap by default. In most cases wherever I want to go to, is on the homerow.

Hey, you can easily configure by variable to use homerow label for EasyMotion. You can't say it is sneak's pros.

Please let me say.

I like vim-sneak, vanilla sneak, but I don't like streak mode because if you want to jump to by label, you should use EasyMotion instead and as far as I know, there is no pros for streak mode than EasyMotion.(if I try to find pros of streak mode, streak mode use conceal feature, but who care?)

Now, EasyMotion can search by two character like vim-sneak and also provide repeat motion including ;,, like motion.

I love vanilla sneak motion, really! So I want @justinmk to improve vanilla sneak motion. It is good but I think there is more room to improve.

For example, it isn't easy to configure omap of vim-sneak, and dot repat don't support c operator. clever-s like feature is good but it could be more sophisticated.

Thanks.

[justinmk]

Hi @haya14busa ,

you can easily configure by variable to use homerow label for EasyMotion. You can't say it is sneak's pros.

Defaults are really important. Now that you are tending to EasyMotion, you will see that 90% of users do not change the defaults :) Sneak's default target labels could be improved though.

Configuration is a pain, so a key part of vim-sneak's philosophy is to figure out the best possible behavior that complements Vim's built-in motions. Configurability also complicates the code.

as far as I know, there is no pros for streak mode than EasyMotion

Well, the details really matter. Some people (new users) like tons of features, but experienced users really care about cohesion, conceptual integrity, and reliability. I think of it as the @scrooloose camp vs the @tpope school.

Here's a thread where I try to list some advantages of streak-mode: #58

However, I noticed that EasyMotion absorbed some of sneak's features, so that may be outdated.

it isn't easy to configure omap of vim-sneak,

As of yesterday, it should be easy. See #57

and dot repat don't support c operator.

Repeat was fixed for all operators (d, c, gu, gU, y, ...) recently too. See 69a305e

clever-s like feature is good but it could be more sophisticated

Interested to hear your thoughts. There's a discussion here: #68

Thanks for your feedback!

[justinmk]

I forgot to mention, there's still an open issue for inclusive f. #64

Also: the key difference between vim-sneak and EasyMotion is that vim-sneak tries to avoid the "choose a label" mode, whereas EasyMotion is constantly presenting one or more stages of target labels, which causes a context-switch each time the user has to make another choice. The idea behind vim-sneak/streak is that the user already knows where he/she wants to go, and the motion should be a batch sequence, not a multi-stage sequence. If there are more than 50-100 matches onscreen, the user isn't gaining anything by using a motion plugin, because those matches can be bisected using built-in Vim motions such as M, H, }, etc.

Actually, that should probably go in the documentation somewhere.

[LFDM]

Yes, jumping to the first match automatically is a huge plus. I notice easymotion has something similar with jump_enter_first

@haya14busa, I have of course changed my default label keys for easymotion, but as @justinmk said, most users probably won't. Would not be a huge change to easymotion to change the built-in default keys of course...

Hm I could easily see easymotio'ns and sneak's feature set getting closer to each other in the future. They are almost doing the same thing right now... Sneak has value because it leightweight, easymotion because it can do almost everything. Not sure both tools have a future. Using them both together (as I am doing it now) is not cool: I am already running out of keys to map, as especially movement tools should be close to reach (like s). I never really used easymotion when I had the default trigger, takes far too much time to type.

I currently see sneak as a best-practices easymotion...

[haya14busa]

Defaults are really important.

Hmm, yeah you are right. I should reconsider it especially 'target_key'. However, you can also say it's not good for plugin to map by default or something.

Actually, Vim itself dose almost nothing by default and provide high configurability. For example, I think 90% users like hlsearch but Vim dosen't configure it by default.

It's true configuration is pain but If the users are true vimmer, I want them to configure it by themselves.

@scrooloose camp vs the @tpope school.

Oh, I'll google it later, Thanks.

Yes, jumping to the first match automatically is a huge plus. I notice easymotion has something similar with jump_enter_first

Oh, I find it jump_space_first like feature should also be implemented, thanks. :)

But jump to first match and showing label at the same time is really intuitive? This is because I like vanilla sneak, and if you support bi-directional cloud search, it will become less intuitive.

I implemented jump_enter_first but I don't frequently use it.

They are almost doing the same thing right now

I want to say EasyMotion also provide JK, word motions in addition to find motion.
EasyMotion aims to jump to anywhere by extending default motion with showing label not only extending 'f'.

I am already running out of keys to map, as especially movement tools should be close to reach (like s). I never really used easymotion when I had the default trigger, takes far too much time to type.
I currently see sneak as a best-practices easymotion...

If you use vim-sneak with streak mode by s, why not nmap <Plug>(easymotion-s2)? You'll say it again default is important?

However, I noticed that EasyMotion absorbed some of sneak's features, so that may be outdated.

Yeah many point is outdated, and this is off topic, but I want to say vim-sneak's readme is wrong. Especially at least 5 key parts is completely wrong and it is not relevant with my updates. EasyMotion provided the way to map before my updates. If you want to say it, add by default.

Thanks.

[LFDM]

I should reconsider it especially 'target_key'. However, you can also say it's not good for plugin to map by default or something.

That's a fair argument, but doesn't really apply to the target keys. This is definetely something I would implement in easymotion: forcing users to a target key map of asdfghjkl... instead of abcdefg... Much more intuitive - most people wouldn't even notice, they just would be better of without even knowing.
Defaults are important. It's just not the case that every vim user is spending hours to configure it - I am sure I do, but generally I think there are more people who just want to get work done without too much hassle - that might come later on then. Thats why janus or yadr are so sucessfull after all. It's also much more likely to get new users when you provide good defaults: If I want to try out a new plugin, I'd better not spend an hour configuring it, before I am able to tell if I want to use it or not. If I like it, I'll look into the configuration afterwards and adjust it to my needs.

I want to say EasyMotion also provide...

There's no argument that easymotions feature set is superior, but I think this misses the point.

If you use vim-sneak with streak mode by s, why not nmap (easymotion-s2)

I've already done that.

In fact, I only discovered that easymotion is revived after starting to use sneak. So I might end up going back to easymotion altogether again.

For what it's worth, the lessons learned by sneak are important: To keep it streamlined and coherent.
You'd probably should join forces imo, taking the best of both worlds - maybe even provide a default sneak-like streamlined mode for easymotion, together with a more complex default setting, that's totally configurable and can do it all.
But I can understand if @justinmk doesn't want to do that, it's fun after all creating such a plugin :)

[justinmk]

You'd probably should join forces imo, taking the best of both worlds

In a way, we already have, except vim-sneak isn't really given explicit credit in the EasyMotion readme/docs. :)

Not sure both tools have a future

Well, EasyMotion was around long before vim-sneak, and has always had more features. But I wanted a single, coherent, minimalist alternative to all the various motion plugins. vim-sneak started out as a better vim-seek, and adding the "EasyMotion" feature was literally only 100 lines of code. It was never meant as a competitor to EasyMotion's kitchen sink--it just applied the EasyMotion concept where it had value, in a limited, focused manner.

I think/hope vim-sneak is very close to being "complete" (until someone finds/suggests a new idea worth incorporating).

vim-sneak is 500 lines of code, EasyMotion is thousands. Some people like nerdtree, but many people just want vim-vinegar.

[haya14busa]

That's a fair argument, but doesn't really apply to the target keys. This is definetely something I would implement in easymotion: forcing users to a target key map of asdfghjkl... instead of abcdefg... Much more intuitive - most people wouldn't even notice, they just would be better of without even knowing.
Defaults are important. It's just not the case that every vim user is spending hours to configure it - I am sure I do, but generally I think there are more people who just want to get work done without too much hassle - that might come later on then. Thats why janus or yadr are so sucessfull after all. It's also much more likely to get new users when you provide good defaults: If I want to try out a new plugin, I'd better not spend an hour configuring it, before I am able to tell if I want to use it or not. If I like it, I'll look into the configuration afterwards and adjust it to my needs.

@LFDM
Yeah, you are right. Maybe I should improve default options or mappings. I opened an issue, so if you are interested in, please give me a good ideas. easymotion/vim-easymotion#85

For what it's worth, the lessons learned by sneak are important: To keep it streamlined and coherent.

I agree. I'll try to make EasyMotion more streamlined and coherent plugin.

You'd probably should join forces
In a way, we already have, except vim-sneak isn't really given explicit credit in the EasyMotion readme/docs. :)

Yes, we already have. I opened issue to vim-sneak and @justinmk give me an example code today.

Yeah, I should link to vim-sneak in a readme or help, but before that, Please remove wrong information of EasyMotion from README of vim-sneak

• minimum of 3 keystrokes (EasyMotion is at least 5)
• move anywhere, even offscreen (unlike EasyMotion)
• repeat the motion (unlike EasyMotion)

I said above, but especially the description, "at least 5" is completly wrong regardless of my updates and I can't think it's credit for EasyMotion.

In addition, I think comparing motion enhancment plugins can be done elsewhere like blog or something. Should it really be mentioned in README? It's maybe good to compare with other plugins to some extent, but there are too much in vim-sneak's README I think.

Well, EasyMotion was around long before vim-sneak, and has always had more features. But I wanted a single, coherent, minimalist alternative to all the various motion plugins. vim-sneak started out as a better vim-seek, and adding the "EasyMotion" feature was literally only 100 lines of code. It was never meant as a competitor to EasyMotion's kitchen sink--it just applied the EasyMotion concept where it had value, in a limited, focused manner.

If you want to say vim-sneak is streamlined and coherent plugin, you should improve vanilla sneak and if you want to implement EasyMotion like motion, it should be implemented another plugin, dosen't it? I think there are few users who use both vanilla sneak & streak mode at the same time.

I can't consider streak mode as streamlined and coherent idea.

vim-sneak is 500 lines of code, EasyMotion is thousands. Some people like nerdtree, but many people just want vim-vinegar.

Yeah, you are right. I want to reduce code but I don't aim to minimal, small code at the expense of configurability and usefulness.

Thanks.

[SevereOverfl0w]

In regards to bidirectional mappings, I've been using this to some success:

map <leader>f H<Plug>SneakLabel_s

It doesn't keep a nice jump history, but it allows for a good alternative to the easymotion-bd-f mapping.

[brendenyule]

I've been using this to some success: map <leader>f H<Plug>SneakLabel_s.

Tried this out today, works well!
Visual selection is very messy though, as the visual highlight covers the character highlight a bit.

Definitely a feature I would love too, destroys easymotion in terms of speed.

[justinmk]

One of these days ... ;)

[justinmk]

AFAICT, "bi-directional" search is neat but useless:

• One wouldn't want it always enabled, because that makes the results noisy all the time
  • ...which means you need at least 2 maps
    • ...which defeats the purpose: the main benefit of bi-directional search is being able to always use the same map without having to think.

[nhooyr]

I don't understand what you mean by one wouldn't want it always enabled. Isn't that the whole point? To always enable it on a single mapping so you don't have to think about which direction from the cursor you want to move?

The results being a little noisy is no problem imo. I'm looking directly at where I want to move, other parts of the screen being labeled isn't that annoying.

[jakubgs]

Agree with nhooyr@. Who cares about "noisy" if I'm already looking at where I want to go?

[justinmk]

Noise means:

• there are twice as many target labels on average
• label-mode will invoke twice as often (fewer opportunities to jump to a single match and skip label-mode)
• half as many labels available in the direction you want to go, which means more steps

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

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

[justinmk]

If label-mode had a way to switch the direction, wouldn't that be a better tradeoff? E.g. if <BS> switched the direction of labels.

Update: done: a0716cd

[nhooyr]

Sounds good to me.

I'd still prefer to not think about the direction, but a mapping to reverse directions good enough, especially considering the other benefits you pointed out.

[jakubgs]

The switching option actually sounds like a really great compromise.

[haya14busa]

no offence to vim-sneak, and i'm not intend to advertise vim-easymotion.... but i'm wondering...
Why not using vim-easymotion?

It has the bidirectional motion feature a way before... let's say... 2-3 years ago. it already implemented the feature.
Even easymotion has the functionality to move to other windows (if you want).

I know some behavior is different from vim-sneak and i'm not intend to argue which behavior is better...

sorry for the noise. I just subscribed this issue because I commented a couple years ago and i cannot help but leaving a comment.

[justinmk]

#62 (comment) is implemented in a0716cd