2

I'm using the xml and omnicppcompl plugins for Vim, and making use of two insert mappings these plugins define for the '>' key. My problem is that while the omnicppcompl plugin will happily imap the '>' key when I enter a buffer of filetype cpp or c, but when it does, the xml plugin's imap of the '>' key will no longer work, as it wont remap itself when I enter a buffer of filetype xml. This causes me to be unable to further use the functionality the mapping provides when I edit xml files, which is to automatically write a closing tag (the omnicppcompl map stays though).

What I'm looking for is that these two mappings are available in their respective filetype, and I believe the issue lies in the xml plugin not remapping itself the way omnicppcompl can. I tried writing quick autocmd's in my .vimrc to manually remap the '>' key, but the xml plugin imap's to a local function in its script with the <SID> bit.

Does anyone know how I can work around this? Is there a way to force the xml plugin to re-run its mapping? I don't know very much about vim scripting and how plugins operate, but is it because the xml plugin has no autoload scripts?

For reference, the xml plugin maps the '>' key on line 1485 of ftplugin/xml.vim, and the omnicppcompl plugin maps the '>' key on line 40 of autoload/omni/cpp/complete.vim

I would greatly appreciate any help and suggestions for how to fix/workaround this.

3

I just gave a quick look at those two files and, from what I gather, it looks like the mapping is done correctly in the xml plugin:

inoremap <silent> <buffer> > ><Esc>:call <SID>CloseTagFun()<Cr>

while it is done incorrectly in the omnicppcomplete plugin:

inoremap <expr> > omni#cpp#maycomplete#Arrow()

When doing that kind of mapping, plugin authors should try to restrict their scope as much as possible: filetype-specific mappings should be buffer-local, using <buffer> as in the first example.

As it stands, depending on how you loaded your files, the cpp mapping may take precedence over the xml mapping because it seems to be too broadly applied to the whole Vim instance instead of cpp buffers.

Additionally, the omnicppcomplete plugin doesn't use ftplugin which is kind of the norm for filetype-specific stuff.

As an immediate solution, I suggest you to add <buffer> to the cpp mapping and, if that works, try to contact the author and convince him/her to modify the plugin upstream.

inoremap <buffer> <expr> > omni#cpp#maycomplete#Arrow()
3
  • Thanks for the insight. I'll try to contact the original author, and for now I've added buffer to that mapping line. We'll see how that goes I guess :)
    – ZeroKnight
    Jun 2 '13 at 7:53
  • Just to be sure, that's <buffer> not buffer.
    – romainl
    Jun 2 '13 at 11:00
  • 1
    Yep, that's what I used. I should have been more specific :p
    – ZeroKnight
    Jun 2 '13 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.