[mini.bracketed] Alternate mappings optimized for bidirectional navigation #1792
Replies: 2 comments 2 replies
-
| Screenshots showing what the mappings look like afterwards:     | 
Beta Was this translation helpful? Give feedback.
-
| 
 Yeah, this is the most visible shortcoming of 'mini.clue' approach to "submodes" when it comes to 'mini.bracketed'. But it is what it is:  
 That does sound interesting and good that it works for you! I personally use "first"/"last" too much to find it comfortable without them. My usual cases are: 
 | 
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
While I really like the functionality provided by 'mini.bracketed', I struggle with the default mappings. I'm simply unable to quickly execute bindings that start with
[or], so repeated presses are especially challenging. I'm not sure if this is because I type in Dvorak, which maps the brackets to-/=keys, or my right pinky is just defective, but this is why I like to use 'mini.clues'postkeysfor all of my bracketed targets. It greatly simplifies repeated target invocation for me, but it only works when navigating in a single direction. As soon as I want to reverse direction, I need to cancel the currentpostkeysoperation and then reach for the other bracket key to change direction.This morning while reviewing my 'mini.bracketed' configuration, I realized that I never use the first or last targets bound to the uppercase version of the suffix. So I thought why not remap the uppercase suffix to go in the reverse direction. For example,
[Dwould move forward instead of going to the first. Likewise]Dwould move backward instead of going to the last. When combined withpostkeys, this lets me very quickly navigate back and forth between targets—especially useful if you overshoot.I thought I'd share my configuration in case others have the same struggles that I have with the defaults:
Beta Was this translation helpful? Give feedback.
All reactions