Conflict handling

[hecal3]

Conflict handling between configuration dictionaries and native vim mappings is currently less than optimal.

A quick example:

let g:lmap.g = { 'name' : 'Git menu' }

nnoremap <SID>git-status :Gstatus<CR>
nnoremap <SID>git-write :Gwrite<CR>
nnoremap <SID>git-diff :Gvdiff<CR>
nmap <leader>gs <SID>git-status
nmap <leader>gw <SID>git-write
nmap <leader>gv <SID>git-diff

This configuration creates a Git menu and some entries.

Now I open a python file using jedi-vim. jedi-vim defines a default mapping <leader>g to jump to the assignment of the current variable.
This conflicts with the git menu. Everything breaks.

There are two obvious way to deal with this:

The easiest solution is to simply not handle conflicts. It's the user's responsibility to keep the mappings in order. So just show some error message and be done with it.
Still, showing mappings in a discoverable way is what this plugin is for. It's those special cases, where mappings are different from what I expect, in which a guide would be especially useful.

The alternative is less clear unfortunately.
I did previously try to come up with something. Right now there is some half baked support, where the original menu [g] changes into [gm] (for g-menu).
There is also the possibility to flatten the display and show the sub menu entries as two letter mappings in the parent menu instead.

All things considered I can't say I'm too happy with the current behaviour.

Another way I can think of is to keep one letter mappings only, and instead insert an intermediate menu, between the parent menu and the conflicting entries, for the user to specify which one it should be.

I'm at loss. Feedback is welcome.
#10

[WuTheFWasThat]

personally, I would be happy with just an error message

the top level menu could show something like

[g] Git menu CONFLICTS WITH @<Plug>(jedi-go-to-assignment)

or something of that nature (and so <leader>g would not be expected to show a menu)