Improve 'mini.jump2d' default config and jumping experience

[echasnovski]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

Module(s)

mini.jump2d

Description

• Update default config.view to have dim = true and n_steps_ahead = 2 (or 1). These were not default because they were not present in the initial release and their values preserved the current at the time behavior.
• Consider having default config.labels as 'asdfghjkl;', i.e. 10 "home row" keys. After test driving them it indeed feels more natural and faster to type, but average label length of targets does go up (less labels -> longer sequences).
• Consider handling <BS> during sequence enter to undo previously typed label.
• Add something like a "smart jump":
  • May or may not have a separate config.mappings.smart_jumping entry. I currently very much like sj: it is in "home row" and works well with 'mini.surround'. It feels better than <CR> (because hands stay on the home row which makes further typing faster) and is almost feels the same as a single s key (which doesn't work with 'mini.surround' and is a bit wasteful).
  • Requires pressing a single character after initiating. That character represents a "jumper identifier" in a concept similar to "textobject/surrounding identifier" from 'mini.ai' and 'mini.surround'. A single jumper is essentially a start() table input or function returning it. This allows customizing everything for any jumper separately: view, labels, allowed_lines, etc.
  • A default jumper reused config values and sets spotter to jump to a cell containing identifier, like builtin_opts.single_character. Should also respect 'ignorecase' and 'smartcase'.
  • Something like <BS> can be used as "return to previous position", which is a more flexible (yet verbose) way of doing "remote operations": jump (like sj-<char>-<seq>) - do operation - sj<BS>. May require exported MiniJump2d.jump_back().
  • Maybe . identifier can be used as "jump to any punctuation group".
  • Maybe <Space> identifier can be used as "jump to any whitespace or line start".
  • Add config.custom_jumpers to customize jumpers for this "smart jumping".

References: #1033, #1755

cc @pkazmier and @abeldekat about possible ideas/feedback here.

[pkazmier]

• Update default config.view to have dim = true and n_steps_ahead = 2 (or 1). These were not default because they were not present in the initial release and their values preserved the current at the time behavior.

This is my preferred setup as well.

• Consider having default config.labels as 'asdfghjkl;', i.e. 10 "home row" keys. After test driving them it indeed feels more natural and faster to type, but average label length of targets does go up (less labels -> longer sequences).

Interesting. I've gone in the other direction where I added the capitals as I prefer shorter sequences. I've not thought about using less labels that were optimized for the home row. I type in Dvorak and I've never changed any mappings to account for that difference, but maybe I'll do a test for a week to pick Dvorak home row to test the general theory about less, but optimized labels, versus shorter sequences.

• Consider handling <BS> during sequence enter to undo previously typed label.

Because I have shorter sequences, this is not important in my day to day use, but if you opt for longer sequences as discussed above then it could become a necessity.

• Add something like a "smart jump":
  • May or may not have a separate config.mappings.smart_jumping entry. I currently very much like sj: it is in "home row" and works well with 'mini.surround'. It feels better than <CR> (because hands stay on the home row which makes further typing faster) and is almost feels the same as a single s key (which doesn't work with 'mini.surround' and is a bit wasteful).

I agree that <CR> is not an ideal mapping—plus you have to unbind it in certain buffers like qf. I find that I don't tend to use jumping as much when it is bound to that key. It's just enough discouragement to sway me to other motions. I prefer using s as my jump key as I use jumping far more often than surround (which I end up binding to gz. I couldn't find a better place for it as the obvious choices of gs or gS are already taken by other mini modules). As for sj, it's easy to type in Dvorak as well, but it'll be a tough sell to have a two character starter sequence. I'll give this a try as well though.

• Requires pressing a single character after initiating. That character represents a "jumper identifier" in a concept similar to "textobject/surrounding identifier" from 'mini.ai' and 'mini.surround'. A single jumper is essentially a start() table input or function returning it. This allows customizing everything for any jumper separately: view, labels, allowed_lines, etc.

This is intriguing. I like the flexibility. I could effectively create Leap's equivalence classes—one of its BEST features imo. I could use ' to label any quote-like characters, [ to label any paren/bracket/brace, and to label lines or first ). On the other hand, having a set of identifiers based on existing text objects might be interesting, although it might require too much mental energy to remember and ultimately just be slower than a more direct approach.

• A default jumper reused config values and sets spotter to jump to a cell containing identifier, like builtin_opts.single_character. Should also respect 'ignorecase' and 'smartcase'.

Agreed on the respecting of case options. I like that Leap doesn't require me to match case.

• Something like <BS> can be used as "return to previous position", which is a more flexible (yet verbose) way of doing "remote operations": jump (like sj-<char>-<seq>) - do operation - sj<BS>. May require exported MiniJump2d.jump_back().

Yes, that would be cool. I don't think making an operating pending remote operation is needed. It's just too much mental energy honestly. I like the idea of a simple backspace to land you back where you were.

Definitely, some good ideas in here. Will be interested in testing them. At the moment, Leap is my favorite jumper as it's the fastest for me. The downsides of it for me are that it requires several mappings. I use s to jump anywhere in window, but need to use S to jump to any other window. And while it has a function to jump anywhere, if you use that, you don't get the benefit of the optimized case where you don't need to enter a label (after entering the 2-chars you are searching for, it jumps to the nearest one, which happens quite often for me).

I know it's not really a jumping capability, but for me, one of the biggest upsides to Leap and Flash over jump2d is that they include the ability to select Treesitter blocks, which I use quite often. While treesitter has the <C-Space> and <BS> to expand selection, it's just too slow and not as direct. I also find the labeling of treesitter blocks to be much easier than trying to remember mini.ai treesitter objects.

[echasnovski]

Thanks for the feedback!

Interesting. I've gone in the other direction where I added the capitals as I prefer shorter sequences.

Yeah, one thing that I think is wrong with 'mini.jump2d' initial design is that "shorter sequence" doesn't always translate into "faster navigation". A slightly longer but more mindless and less movement typing can be faster. This is somewhat aligned with your original discussion about "mental pauses".

I agree that <CR> is not an ideal mapping—plus you have to unbind it in certain buffers like qf. I find that I don't tend to use jumping as much when it is bound to that key. It's just enough discouragement to sway me to other motions. I prefer using s as my jump key as I use jumping far more often than surround (which I end up binding to gz. I couldn't find a better place for it as the obvious choices of gs or gS are already taken by other mini modules). As for sj, it's easy to type in Dvorak as well, but it'll be a tough sell to have a two character starter sequence. I'll give this a try as well though.

Yes, I do truly understand that one key is better than two. I tried finding the best one-key mapping, and nothing quite fits:

• There is <Tab>, but it requires the same small movement as <CR>. Plus it might be a better mapping for something directional, as there is <S-Tab> to counter it (i.e. for "go in other direction").
• The least disruptive single letters are m and x, but they still are useful.

The sj fits the mnemonic ("smart jump" or "start jump"), is in home row, and will also fit in possible future operators/actions that will start with s (as starting with g is a bit crowded already). And with some practice it is indeed almost the same as pressing single s (as s and j are in home row for different hands). So for Dvorak to have the same effect, I'd recommend something like su or hu, i.e. consisting from home row keys with one for each hand.

Another "creative" idea is to use MiniKeymap.map_combo to map something like jk in Normal/Visual/Operator-pending mode to start jump. But that is outside of 'mini.jump2d', so can only be done in user configs.

This is intriguing. I like the flexibility. I could effectively create Leap's equivalence classes—one of its BEST features imo.

Yes, your mentioning that features is what drove the idea. So thank you for that :)

On the other hand, having a set of identifiers based on existing text objects might be interesting, although it might require too much mental energy to remember and ultimately just be slower than a more direct approach.

Just to clarify, there will be nothing based on text objects. It is just the same idea with "action" - "id" workflow. By default all lower letter identifiers will act like current builtin_opts.single_character: i.e. spotter will only find cells with that character.

I know it's not really a jumping capability, but for me, one of the biggest upsides to Leap and Flash over jump2d is that they include the ability to select Treesitter blocks, which I use quite often.

Yeah, we discussed it earlier and this type of functionality is planned from 'mini.hierarchy' (either directly or in combination with 'mini.ai').

But the proposed design will allow that as well. Something like T jumper that shows only visible starts of tree-sitter nodes with a after_jump hook that selects the entire node. This should even be possible with the current 'mini.jump2d', just under a dedicated mapping.

[pkazmier]

Thanks for the feedback!

Interesting. I've gone in the other direction where I added the capitals as I prefer shorter sequences.

Yeah, one thing that I think is wrong with 'mini.jump2d' initial design is that "shorter sequence" doesn't always translate into "faster navigation". A slightly longer but more mindless and less movement typing can be faster. This is somewhat aligned with your original discussion about "mental pauses".

Yeah, I tested the shorter labels with the equivalent Dvorak home row briefly, I'm not sure I liked it. Will keep testing though. [edit: been trying it longer and I can confidently say I don't like it].

Yes, I do truly understand that one key is better than two. I tried finding the best one-key mapping, and nothing quite fits:

• There is <Tab>, but it requires the same small movement as <CR>. Plus it might be a better mapping for something directional, as there is <S-Tab> to counter it (i.e. for "go in other direction").
• The least disruptive single letters are m and x, but they still are useful.

You've just given me the perfect answer for me. I'm taking m for my new jumper key. And I'll move marks to M as I don't use them as often as I would jumping. And I have never ever used the former M command. Thanks!!

On the other hand, having a set of identifiers based on existing text objects might be interesting, although it might require too much mental energy to remember and ultimately just be slower than a more direct approach.

Just to clarify, there will be nothing based on text objects. It is just the same idea with "action" - "id" workflow. By default all lower letter identifiers will act like current builtin_opts.single_character: i.e. spotter will only find cells with that character.

I understand. But my brain immediately went to the "what if" I made a set of identifiers to speed jumping: p for a spotter that labels all paragraphs, w for spotter that labels all words, . for all punctuation, b for all braces, q for all quotes, etc ... Yes that would defeat the default jumper, but I could have an identifier, maybe m (assume I use m to initiate a jump per comment above) to activate the single_char behavior. Then mmp would spot all p's. mm is very fast to get the behavior of single_char today, but with the other shortcut identifies I could get to places ever faster. Just thinking out loud.

[echasnovski]

You've just given me the perfect answer for me. I'm taking m for my new jumper key. And I'll move marks to M as I don't use them as often as I would jumping. And I have never ever used the former M command. Thanks!!

Mission of promoting sj failed successfully 👍

I understand. But my brain immediately went to the "what if" I made a set of identifiers to speed jumping: p for a spotter that labels all paragraphs, w for spotter that labels all words, . for all punctuation, b for all braces, q for all quotes, etc ...

Ah, I see what you mean. I thought about possibly making some of these built-in but under the capital letters. I think optimization should go towards default "single char" (i.e. it should be easier to initiate) and not the other way around.

[abeldekat]

Last February I switched back to leap after having used jump2d for 6 months. This PR is an excellent opportunity to reconsider.

I learned that I really value key s to start the jump because the enter is on the least powerful finger. The ability to always type the first 2 characters directly after start, without thinking and visual clutter, is important. It's nice that leap shows the hint for the third character to type ahead of time, but not crucial. Most of the time I type s-char1-char2 so fast that there is still a little interrupt before my brain processes the hint.

I very much agree with the following:

A slightly longer but more mindless and less movement typing can be faster

This is also one of the reasons I switched back to leap. I remember writing this comment, describing how fast I can navigate with the suggestions provided by jump2d. However, there was a gaming aspect involved when I wrote that comment. From my perspective, during normal editing, the pattern I can type "mindlessly" are the first two characters of the spot I want to target.

The remote feature in leap is not important to me, I rarely use it (yr, yank remote).
The incremental selection feature is a little more than nice. I can wait for mini.hierarchy though.
I agree with pkazmier that the equivalence classes in leap are awesome.

Indeed, the s key does not play well with surround. I solved that by using ma ms md mf for surround, remembering that the first four letters in the homerow(asdf) cannot be used for marking. This is the opposite approach as described by pkazmier.

Regarding the proposals in this PR, I support the suggested new defaults. The smartjump is a really nice idea!

Inspecting jump2d once more, I discovered that I can extend the idea of the single char spotter. Now I can type the first two chars of the spot I want to target, take a mental pause to process the suggestion by jump2d, and continue. I am going to use this config for a while and consider adding this to the show and tell section....)

From my perspective, I would like to have the equivalence classes functionality, and an ignore-case/smartcase search.

I also would like to have another way to distribute the labels. The order of the characters in config.labels could indicate priority. The most important characters will be used as hints for the matches closest to cursor. I don't mind that bigger jumps are a bit more difficult/expensive to type. It's more important that closer jumps are easier...

[echasnovski]

Thanks for your feedback as well!

The ability to always type the first 2 characters directly after start, without thinking and visual clutter, is important. It's nice that leap shows the hint for the third character to type ahead of time, but not crucial. Most of the time I type s-char1-char2 so fast that there is still a little interrupt before my brain processes the hint.

Hmm... Maybe the default fallback jumper can be made configurable about how many more keys it asks to narrow down the spots. Value 0 is then equivalent to "single character", value 1 to "two characters", and so on. Pressing <CR> stops querying target characters. This might help with less available labels by default at the cost of being slightly more confusing. I will think more about it.

Indeed, the s key does not play well with surround. I solved that by using ma ms md mf for surround, remembering that the first four letters in the homerow(asdf) cannot be used for marking. This is the opposite approach as described by pkazmier.

Yeah, to each their own, I guess. The most important aspect here is that 'mini.nvim' defaults should play nicely with each other while being as ergonomic as they can. I still think sj as default should be ok. If people prefer using s or m, it is customizable.

I also would like to have another way to distribute the labels. The order of the characters in config.labels could indicate priority. The most important characters will be used as hints for the matches closest to cursor. I don't mind that bigger jumps are a bit more difficult/expensive to type. It's more important that closer jumps are easier...

That, I am afraid, won't happen. Label computation that depends on cursor is something that I personally really don't find intuitive. It was also one of the main drivers to write 'mini.jump2d' as alternative to 'hop.nvim'.

[abeldekat]

Hmm... Maybe the default fallback jumper can be made configurable about how many more keys it asks to narrow down the spots. Value 0 is then equivalent to "single character", value 1 to "two characters", and so on. Pressing stops querying target characters. This might help with less available labels by default at the cost of being slightly more confusing. I will think more about it.

That would be nice!

Yeah, to each their own, I guess. The most important aspect here is that 'mini.nvim' defaults should play nicely with each other while being as ergonomic as they can. I still think sj as default should be ok. If people prefer using s or m, it is customizable.

Yes, agree. Key sj makes sense.

[pkazmier]

Ah, I see what you mean. I thought about possibly making some of these built-in but under the capital letters. I think optimization should go towards default "single char" (i.e. it should be easier to initiate) and not the other way around.

Ah, yes, good point. I like the idea of using the capitals for the built-ins.

Hmm... Maybe the default fallback jumper can be made configurable about how many more keys it asks to narrow down the spots. Value 0 is then equivalent to "single character", value 1 to "two characters", and so on. Pressing stops querying target characters. This might help with less available labels by default at the cost of being slightly more confusing. I will think more about it.

Yes, that would be nice. Like @abeldekat I've been using leap for a while and I think I've become accustomed to two character input, but only if the concept of equivalence classes exists still for the second character. This becomes incredibly important when jumping to end of line. In leap, you type the last character on the line followed by a space (defined as an equivalence of newline).

[echasnovski]

... but only if the concept of equivalence classes exists still for the second character. This becomes incredibly important when jumping to end of line. In leap, you type the last character on the line followed by a space (defined as an equivalence of newline).

Hmm... I see that this is a valid use case, but currently doesn't really fit the proposed solution. Will have this in mind.