Beta-testing 'mini.jump2d'

[echasnovski]

Please leave your feedback about new 'mini.jump2d' module here. Feel free to either add new comment or positively upvote existing one.

Some things that I am interested to find out (obviously, besides bugs):

• Are configuration and function names intuitive enough?
• Are default values of settings convenient for you?
• Is documentation clear enough?

[Iron-E]

I came to this from lightspeed.nvim. I didn't expect to only be able to jump to beginnings or ends of words at first; I realized that doesn't really matter since you can just use mini.jump to get to an exact position after a mini.jump2d. Feels very fast, even on old hardware

[echasnovski]

That is great to here, hope you'll like it!

My initial idea was something along the lines "I want to jump to any non-whitespace in a matter of couple of keystrokes". So when after implementation, it felt unusable (or, at least, needing much time to get used to). The reason for me was that I immediately lost the place where I wanted to jump. Looked cool though! You can try this with lua MiniJump2d.start({ spotter = MiniJump2d.gen_pattern_spotter('%S') }).

So after trial and error I figured that I very rarely needed to jump inside word between letters. Usually it is "jump to word -> replace whole word". But jumping to place near punctuation or start of capital letter is quite frequent in programming. Thus was the default spotter born.

[JoseConseco]

One thing could be changed, default labels :
keys = 'asdghklqwertyuiopzxcvbnmfj' - are more ergonomic than default 'abcd...' labels from jump
These are from hop (can be costomized)

[echasnovski]

Thanks! Yeah, I thought about that. And while those might be "ergonomic mechanically" they don't feel "ergonomic mentally" to me. It seems more intuitive to have "a" at start and "z" at end, albeit maybe slightly worse to type. And also this won't have the same effect as in 'hop.nvim' because labels are computed not around cursor, so any label is more or less equally possible on first step.

But they are customizable, so don't think this should matter much.

[BenjaminKern]

I was trying initially to migrate from hop, but unfortunately y1 yank motion was broken. In addition, I am using https://github.com/rcarriga/nvim-notify, and the vim.notify messages are very noisy. It would be great to be able to disable this notifications somehow

[echasnovski]

Thanks for the feedback!

• Could you, please, tell more about "y1 yank motion was broken"? I don't quite understand that.
• I am not using 'rcarriga/nvim-notify' myself, so didn't take that into account. All 'mini.nvim' modules are using vim.notify at the moment for user-facing messages. I am leaning towards changing that to plain old :echomsg. Or make it work with vim.notify, not really sure, but that is being worked on.

[BenjaminKern]

I will try to reproduce this problem and make an separate issue for that once I find the time

[JoseConseco]

Hi @echasnovski i was recently trying to implement repeat functionality in my custom Text Object. Turns out u have to use vim-repeat plug to make it work, and here is my sollution:
tpope/vim-repeat#92 (comment)
I wonder can this be used to repeat jumps with jump and/or jump2d ?

[echasnovski]

First, in order for custom textobject to support dot-repeat, you usually don't have to use 'tpope/vim-repeat'. 'mini.nvim' has several text objects and motions, all of them support dot-repeatability out of the box. Usually it is a matter of making a correct mapping for using it. Situations might be different, but you can try to look at source code of 'mini.comment' (starting from here) or 'mini.indentscope' (starting from here).

Second, jumps in 'mini.jump' are fully dot-repeatable: typing dto will delete till first o; then typing . will again delete till first o.

Third, jumps in 'mini.jump2d' are dot-repeatable to the extent I currently see reasonable: d<CR>aa will delete up to spot defined by two as; then typing . will automatically "know" that user wants to do delete using 'mini.jump2d' and start jumping. It is not (and probably will not under this design) possible to replace f with 'mini.jump2d' functionality so that it "remembers" the last target character. This would require some caching magic currently implemented in 'mini.surround' (quite complicated and I will use this approach only if totally necessary).

[echasnovski]

@BenjaminKern, I stopped using vim.notify() for frequent user notification in favor of good old echomsg. Now it should be less noisy.

[BenjaminKern]

Awesome, thanks

[BenjaminKern]

Maybe a quick feedback after using jump2d for a couple of days. I am often in the situation, where i need to jump 3-4 times to get to the location, where I want, while with hop it usually takes two jumps. I have a feeling that this happens when I want to jump to a location that is not so far away.

[echasnovski]

Thanks for the feedback, it really helps!

I presume you mean "keystrokes" instead of "jumps" here. Well, yeah, that is one of the intentional main differences between of 'hop.nvim' and 'mini.jump2d'. Former computes labels with algorithm involving cursor position, latter - doesn't. And so it takes roughly a uniform amount of keystrokes to get to any allowed spot instead of "fewer near cursor". (Also, is this an estimate for the same allowed jump spots? Like both "word starts in current window" or "default 'mini.jump2d' and some specific command in 'hop.nvim'"?).

When I tried 'hop.nvim', for some reason this asymmetry in label computation was a deal breaker to try and write 'mini.jump2d'. Besides, found using this type of jumping usually to go relatively far enough from current cursor position (otherwise using builtin motions), so 'mini.jump2d' is usually narrowing allowed spots somewhat quicker.