Can we configure mini.jump2d to have "immutable" labels similar to hop and easymotion

[farzadmf]

Hi, I was wondering if there's a way to configure mini.jump2d to have its labels similar to hop.nvim

I read the help, and it mentions that hop creates different labels, some longer, some shorter, etc., but that's not what I have in mind.

What I like about hop is: when I want to jump somewhere, and I see a label for it, I can just quickly memorize the label, type the label, without me looking at it (that's not what I normally do (not looking and typing the label, but I hope you get the idea))

This is not what happens in mini.jump2d:

• When I press <cr>, I see the label I want to jump
• I press it, and it becomes another character, and my brain needs to spot the new character and type it

I totally get that this might make the number of steps somehow consistent no matter where you're jumping, but I personally like how easymotion and hop do it: you get a label (sometimes maybe even 3 chars), your brain registers it and you just type

Well ... sorry for the long story! I REALLY like mini modules so much that my default is: "use the alternative if the mini one really, really doesn't work for you" (and that rarely happens)

If you can please help me so that I can onboard another mini module, I'd appreicate it so much

• I was using hop, but it had some weird bugs that I had to give up using it
• I'm using leap, but that doesn't resonate with me at all (and its counterpart flit is not working as I expect it to)

[echasnovski]

If I understand you correctly, you'd like 'mini.jump2d' to show whole sequence of characters at once after initial start()? If yes, then unfortunately it is not possible and likely won't happen (and even is a documented difference with 'phaazon/hop.nvim').

The are at least these reasons:

• Less visual clutter for same number of possible jump locations (or more locations for same amount of visual clutter).
• Easier and more unambiguous implementation. Having whole sequence showed means that module has to deal with possible overlapping which is not an easy thing to do. Right now it is single character for a single jump spot.

That said, I also occasionally notice a slight inconvenient delay needed to register which key I should press next. It has not yet outweighed previous reasons, though :)

[farzadmf]

Thank you @echasnovski , and sorry for the late reply.

Yeah, I think that's what I had in mind: basically to show the "overlay" once and know what I need to type to reach there. I really wish there was a way since I'm super used to it. Even I use the tmux-jump in tmux, which follows the same concept as easymotion (and hop).

I honestly really wish it could have been possible with mini.jump2d, but I completely understand if you don't feel like it's not something useful; it's your plugin and you're the boss 😆

[echasnovski]

@farzadmf, I've just stumbled on this question again. This has already been possible for a while with a more granular view.n_steps_ahead setting. Set it to a very high number to always show all necessary sequence of labels.

It did eventually outweigh the previous reasons after I became aware of 'hop.nvim' eventual "end of support" by the author. So decided to get 'mini.jump2d' to a more feature parity with 'hop.nvim', although didn't end up using view.n_steps_ahead setting myself.

[farzadmf]

@echasnovski thank you so much for taking the time to reply to this; I appreciate it.

Yeah, I think we had a discussion on Reddit when you announced the feature parity with hop.nvim.

Now that I have you here: since you and folke are the only ones where I try to use any plugins you guys create 😆, what do you think about flash.nvim from him? Is it a replacement for mini.jump2d (and possibly mini.jump)?

[echasnovski]

@echasnovski thank you so much for taking the time to reply to this; I appreciate it.

Yeah, I think we had a discussion on Reddit when you announced the feature parity with hop.nvim.

Yeah, I remember that. Didn't realize it was with you.

Now that I have you here: since you and folke are the only ones where I try to use any plugins you guys create laughing, what do you think about flash.nvim from him? Is it a replacement for mini.jump2d (and possibly mini.jump)?

It certainly is good and high quality. Among its examples there is a possible imitation to 'mini.jump2d'/'hop.nvim' approach to computing targets, but it does not provide quite the experience.

Generally, there are at least following differences between 'mini.jump2d' and 'flash.nvim':

• Overall design. 'flash.nvim' basic idea is to use regular (Neo)Vim search approach to both define and narrow down target until it is close enough to have label available for it. It is very flexible and fast evolving, so there are others approaches. 'mini.jump2d' idea follows 'hop.nvim' one: precompute all targets in visible windows and efficiently "code" each one using available labels. User then needs to type those labels until desired target is narrowed down.
• Label computation. Main approach for both 'flash.nvim' and 'hop.nvim' is to compute labels based on the distance to cursor. 'mini.jump2d' computes them in order labels are positions (without taking cursor into account). Now, 'flash.nvim' does have label.distance option to turn it off, but even then it has slight differences.
• Showing all steps ahead. At the moment 'flash.nvim' shows only one step label at a time (as was 'mini.jump2d' earlier). 'mini.jump2d' and 'hop.nvim' can show ahead.
• Minor details (which might get fixed at some point). Like 'flash.nvim' doesn't play nice with folds, for example.

All in all, I feel that, at its core, this is mostly a matter of preference which approach to narrowing down target spot user prefers. If both initiate and narrow down as in regular search (usually not the most efficient in terms of key strokes and time spent, but can feel easier for some people), then use 'flash.nvim'. If precompute certain targets and narrow them down by typing label sequence, then 'mini.jump2d'.

[farzadmf]

GREAT answer @echasnovski (didn't expect any less). I'm yet to try flash.nvim, but I'll give it a shot and compare.

I guess healthy competition helps evolve an ecosystem.