Go To Link Command Inconsistencies with Cursor Position, Live Preview, and Vim Mode

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 :white_check_mark: represents a position where “alt +enter” properly opens the link, while :x: 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 :x: 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:
image
fig 1.1

After two ctrl + right arrow presses: :x:
image
fig 1.2

Move one char over: :white_check_mark:
image
fig 1.3

If you use ctrl + right arrow again instead: :white_check_mark:
image
1.4

Moving to link from the following word:

Starting position:
image
fig 1.5

Use ctrl + left arrow: :white_check_mark:
image
fig 1.6

Now in Vim mode

Starting point:
image
fig 2.1

Use a “w” motion to go to front of link: :x:
image
fig 2.2

Over one more char: :white_check_mark:
image
fig 2.3

If you use another “w” motion instead: :white_check_mark:
image
fig 2.4

Moving to link from the following word

Starting position:
image
fig 2.5

Use a “b” motion: :x:
image
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: :white_check_mark:
image
fig 2.7

Proposed solution

The solution would be to

  1. Make “alt + enter” work in the position shown in figures 1.2 and 2.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.

2 Likes

Experiencing the same issue, if you’re using the vimrc Support Plugin you can add the following as a workaround (make sure to unbind the existing Alt-Enter hotkey)

" Make Alt-Enter follow link
exmap followLink obcommand editor:follow-link
nmap &c& :followLink
nmap <A-CR> lBl&c&