Mappings clash

[ghost]

I mapped my <C-Space> to something I use fairly often, thus whenever ftplugin/c/previewWord.vim loads, there is an error (which appears whenever I open a C file) because it tries to redefine <C-Space> in line 43.

[LucHermitte]

Hi,

I mapped my <C-Space> to something I use fairly often, thus whenever ftplugin/c/previewWord.vim loads, there is an error (which appears whenever I open a C file) because it tries to redefine in line 43.

I see that I've forgotten to define these mappings as <buffer> local. I'll submit a patch shortly.

In case this is not enough, you must know that the mappings are defined through <Plug>Mappings. If you still have clashes, you'll have to choose the key to which you'll bind the mappings. It has to be done in a C ftplugin that'll get loaded before c/previewWord.vim (typically $HOME/.vim/ftplugin/c_personaltunings.vim) You can check the loading order by echoing &rtp option.

Either you want to use the mappings, in that case do something like this in the new ftplugin

imap <unique> <buffer> <localleader>whateverbinding <Plug>PreviewWord
nmap <unique> <buffer> <localleader>whateverbinding <Plug>PreviewWord

Or define in that file

let b:loaded_ftplug_previewWord = 1

to prevent the ftplugin to be loaded.

[ghost]

Thanks for the quick response and thanks for doing this plugin! Wouldn't it be best to let the user define the mapping him/herself through variables?

[LucHermitte]

Thanks for the quick response and thanks for doing this plugin!

You're welcome!

Wouldn't it be best to let the user define the mapping him/herself through variables?

That's a good question. Nowadays, I feel that <Plug>Mappings are a far superior version than variables. This way, we know when there is a clash, and we're still able to override the default settings we propose in plugins.

However, I must admit that in the case of ftplugins, overriding is a quite cumbersome. I guess I'll to think about it some day.

Right now I'm in another big development phase: I'm introducing p:var (for project variables) in lh-vim-lib in order to simplify the way options are stored for compilation, tag generation and so on.

[LucHermitte]

@lucasmelo Has my patch fixed the issue you've encountered?

[ghost]

I got the following error message:

Error detected while processing ~/.vim/bundle/lh-cpp/ftplugin/c/previewWord.vim:
line   43:
E225: global mapping already exists for <80><fc>^D

Also, an lh-dev error:

Error detected while processing ~/.vim/bundle/lh-dev/autoload/lh/dev.vim:
line  122:
E117: Unknown function: lh#tags#ctags_flavor
E15: Invalid expression: lh#tags#ctags_flavor() == 'utags'  

[LucHermitte]

Hi. Sorry for the delay. The error related to lh-dev should be fixed by now.

I still have to investigate the E225. But I'm afraid the solution would be what I've described in my first comment:

" $HOME/.vim/ftplugin/c_personaltunings.vim
imap <unique> <buffer> <localleader>whateverbinding <Plug>PreviewWord 
nmap <unique> <buffer> <localleader>whateverbinding <Plug>PreviewWord

"or

let b:loaded_ftplug_previewWord = 1

[ghost]

Mapping something to PreviewWord will prevent it from being mapped somewhere else?

I think the solution of setting b:loaded_ftplug_previewWord to 1 would definitely work, but wouldn't it remove certain functionality from the plugin?

[LucHermitte]

Mapping something to PreviewWord will prevent it from being mapped somewhere else?

Yes. That's the idea. That's because I check whether there already is a mapping to <Plug>PreviewWord before providing a default mapping. That's how plug-mappings are meant to be used. It's up to the final users to chose something more adequate to their tastes and to their constraints -- I found plug-mappings more flexible than mappings using the leader-key (in plugin definition)

I think the solution of setting b:loaded_ftplug_previewWord to 1 would definitely work, but wouldn't it remove certain functionality from the plugin?

Yes it would remove a feature. Now, to be perfectly honest, I haven't used it in many years -- dare I day a decade? I'm not even sure it's documented.

[mellery451]

I was having the same error and just ended-up adding this to my vimrc to verify the workaround:

imap <buffer> <unique> <leader>pw <Plug>PreviewWord
nmap <buffer> <unique> <leader>pw <Plug>PreviewWord

...and it got past that original error. Now it turns out I have other mapping conflicts (for example <leader>sf and <leader>sc were already taken by me).

Do you know any good way to evaluate mapping conflicts between plugins and/or my vimrc to figure out what I need to disable or change to make everything play nicely together?

[LucHermitte]

The .vimrc is not the right place to define this mapping. Mappings done in the vimrc are executed once. However, <buffer> mappings shall be executed once for every buffer (where they should apply). If you override the mapping in your .vimrc, then remove the <buffer> annotation, but be aware, the keybinding will dangle on an undefined sequence with non C/C++ filetypes.

BTW I see that my test with hasmapto is incorrect as it doesn't test whether there is a mapping for the current buffer. I'll update it.

Back to your question, we can investigate conflicting mappings thanks to maparg(). If we want to know where a mapping has already been defined, we :

• either have the old approach like: verbose imap <leader>sf, which is neat for end users,
• or we can look at the sid key in :echo maparg('<leader>sf>', 'i', 0, 1), and compare it to :scriptnames result. As you already have lh-vim-lib, you can simply echo :echo lh#askvim#scriptname(maparg('<leader>sf>', 'i', 0, 1)). This approach is more interesting when writing plugins.

You'll see a commit in lh-vim-lib that relates to this point. I've also fixed this ftplugin to default the mappings to localleader this time.

[mellery451]

thank you for this info and fix. I removed my hack in vimrc and updated to latest. I now see the warnings about conflicts but they are not fatal and it gives me a chance to go resolve them on my own, which I think is perfect. 👍