Disable or remap `ge`

[mawkler]

vim-markdown overwriting ge is quite critical, as its default mapping is a very useful (at least to me) movement.

I think that vim-markdown should have a setting that I could set to disable or remap vim-markdown-ge to something else.

[leesoh]

Agreed. It would be great to either change this default or allow it to be remapped.

[danielfalbo]

+1

[danielfalbo]

This is my temporary solution, from the README.md:

Disable Default Key Mappings
g:vim_markdown_no_default_key_mappings

Add the following line to your .vimrc to disable default key mappings:
let g:vim_markdown_no_default_key_mappings = 1

You can also map them by yourself with mappings.

[mawkler]

By remapping <Plug>Markdown_EditUrlUnderCursor, vim-markdown's default ge mapping disappears, so my solution is to remap it to <F13> (a valid remap to a key that doesn't exist on most keyboards) like so:

map <F13> <Plug>Markdown_EditUrlUnderCursor

A built in toggle in vim-markdown to enable or disable the ge mapping would be a nicer solution, but this works.

[fourpastmidnight]

I agree with @melkster, a plugin should not override default vim commands. And if a plugin author really wants to use a keymap that conflicts with a default vim command, then they ought to consider using a <leader> key mapping instead. However, there are other (unused) key combinations which could be considered in this specific case:

• eu for <Plug>Markdown_EditUrlUnderCursor
• ju for <Plug>Markdown_OpenUrlUnderCursor (think, j for jump) instead of the current mapping of gx.

[ernstwi]

Both eu and ju would be annoying as they cause the very common j and e movements to wait for ttimeoutlen, no? Better to use a leading character which is already used in two-button maps, such as g or <leader>.

There is a complete list of default commands starting with g at :help g.

[fourpastmidnight]

@ernstwi You're so right! How silly of me. Then I agree, better to use a <LocalLeader> mapping (since these mappings only apply to the buffer which is detected with a filetype of markdown), as the two-letter g "command-space" is already awfully crowded.

[alerque]

I would be happy to review/accept a PR that moved the default binding to this to something that is not used by default in VIM/NeoVIM. As noted eu etc. will not work, but there are surely other options.

[alerque]

In #582 @ernstwi proposed using gy. Perhaps more importantly he has also dug up all the places thin needs to get fixed if we change it.

I can see the argument for the synergy with gx, but it still doesn't sit great with me. If that's what other people support I'll be happy to cede and let that go through, but first I'd like to float my own suggestion:

My idea is gl (as in goto link). Does that resonate better than gy with anyone?

[mawkler]

Why not have it mapped to gf and have it overloaded so that gf also works as usual on "regular" file paths? gf is already a built-in Vim concept (go to file).

[alerque]

@melkster That actually sounds like a good idea to me, the only downside is it has some implementation overhead that I don't have time to contribute myself. I'd be happy to approve a contribution that took it that direction, but if somebody is going to do that it should probably happen soon or we should go ahead with changing the default binding to something else (since that is well agreed to be a problem and a contribution is already ready to take care of it).

[ernstwi]

Liking the gf idea as well. I'll have a look now and see if it's easily doable.

[ernstwi]

Didn't have time to finish a PR for gf today, but will return to it when I get the time unless someone else does. Should work out good.