Use case or problem
I’ve been experiencing inconsistencies with the Go to Link command (“alt + enter” hotkey) that I have been subconsciously compensating for, but they are actually just some obscure UX problems that need to be ironed out. I went through great lengths to take many screenshots to thoroughly describe the issue and UX flow.
When using “alt + enter” hotkey to open an internal link under cursor, there are some cursor positions where it should work, but does not, forcing the user to input extra movements until the cursor is in a position that works.
The following graphics show different positions and how you might end up in those positions while you are moving back and forth between words, either with “ctrl + arrow key” movements, or with Vim motions. A represents a position where “alt +enter” properly opens the link, while means “alt + enter” doesn’t do anything in that position.
Fixing these minor issues would make it so that links could be navigated to and activated with 1 less key press in almost all cases. But in reality I end up needing even more key presses due to trying and failing to open the link in one of the positions, and having to correct. That little bit of friction adds up over time.
Without Vim mode
The behavior when Vim mode is enabled and insert mode is active is identical.
Starting position:
fig 1.1
After two ctrl + right arrow presses:
fig 1.2
Move one char over:
fig 1.3
If you use ctrl + right arrow again instead:
1.4
Moving to link from the following word:
Starting position:
fig 1.5
Use ctrl + left arrow:
fig 1.6
Now in Vim mode
Starting point:
fig 2.1
Use a “w” motion to go to front of link:
fig 2.2
Over one more char:
fig 2.3
If you use another “w” motion instead:
fig 2.4
Moving to link from the following word
Starting position:
fig 2.5
Use a “b” motion:
fig 2.6
fig 2.6 actually demonstrates a seemingly unrelated bugged interaction between Live Preview and Vim mode. In real Vim (ignoring Live Preview), the position after “b” shown in fig 2.6 should have been the position shown in fig 2.7.
Another “b” motion:
fig 2.7
Proposed solution
The solution would be to
- Make “alt + enter” work in the position shown in figures 1.2 and 2.2
- Fix the interaction between Live Preview and Vim mode that results in the position shown in figure 2.6, instead of the correct position shown in figure 2.7
Current workaround
My current workaround is to simply use more key presses than should be necessary.