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.

[ernstwi]

Note: I use ge to refer to the edit markdown link function here, not the particular mapping.

The idea of overriding gf is complicated by these options:

1. g:vim_markdown_edit_url_in
2. g:vim_markdown_autowrite
3. g:vim_markdown_follow_anchor
4. g:vim_markdown_anchorexpr
5. g:vim_markdown_no_extensions_in_markdown
6. g:vim_markdown_auto_extension_ext

These all affect the behaviour of ge on markdown links – the question is which of these would we like to also apply to the gf fallback.

I think that 3, 4, 5, and 6 could be ignored without breaking the user's expectation. But if I have 1 set to e.g. vsplit, it seems messy that the same keys gf should open a file in a vertical split if the link is markdown, and in the same window (default for gf) if the link is a normal filename.

On the other hand, if we apply special behaviour to gf from options 1 and 2 we now have a slightly different version of gf that only applies when in a markdown buffer... Also not ideal. I don't think we should change the default gf at all if we override it.

I think that short of removing options 1 and 2, it would be best to keep ge on its own mapping.

---

By the way, ge as it is now actually already falls back to editing <cfile>, the filename under cursor, when not on a markdown link. This implementation respects option 1 but not 2, I documented this behaviour with some tests in #586 .

Could be easily fixed to support option 2 as well, but I think that if we decide to keep separate ge/gf it would be better to remove ge's fallback entirely.

---

So as a summary I think it would be best to:

• Change ge mapping to gl
• Remove the fallback for non-markdown links for gl

[ernstwi]

So as a summary I think it would be best to:

• Change ge mapping to gl
• Remove the fallback for non-markdown links for gl

To push this forward I updated PR #582 to use the gl mapping suggested by @alerque.

Second step if you agree might be to update #586 for bullet point 2 above, let me know.