<Tab> inserts '<t_ý>SSuperTabForward' instead of triggering completions about supertab

[StanAngeloff]

Oh well, garbas/vim-snipmate works like a charm! Self-close.

EDIT: re-opening as it still happens on <C-P> and <C-N>, but not on <Tab>.

[ogier]

For what it's worth, I get similar behavior. In my case it seems that any mapping that contains <Plug> fails to execute. My inserted text is <Plug>SuperTabForward. It's not specific to SuperTab, it's just that SuperTab is one of the only plugins I use that has imap bindings with <Plug>, which means that extraneous text gets inserted instead of the plugin just silently doing nothing. Other plugins such as tpope/vim-surround that use <Plug> for nmap bindings just don't work at all.

This happens on ArchLinux and CentOS 6.3 for me.

[ogier]

So I rooted out the problem. Apparently the way plugins use <Plug> bindings means that their bindings are translated according to langmap. At least, setting langmap to anything that intersected the letters in a <Plug> binding broke the binding for me. I don't know if this is an upstream bug in vim proper or not, but removing my langmap setting fixed these bindings.

[ervandew]

Can you post an example langmap value which triggers the issue? This could either be a vim bug or it could have to do with the way supertab creates its mappings.

[ogier]

langmap=ef triggers it, for example. Basically, the righthand side of bindings is translated when it gets executed according to langmap. For a silly example, the following works correctly:

:set langmap=px,xp
:inoremap <Tab> <Plug>SuxerTabForward

So far as I can tell, the only way to reliably work around this issue is to have the results of all your mappings be ex-mode commands. Of course, presumably this relies on not remapping the : character (I don't do this, but someone else might).

This seems to be an upstream issue, I can't think of any situations in which translating the right-hand side of a mapping by langmap is useful. I ranted a bit about it on the vim dev mailing list, though they haven't approved my email yet.

[ervandew]

I'm going to play with it some more tomorrow, but yeah this is looking like a vim issue to me as well. The way the mappings are defined certainly isn't the problem since I can toggle the langmap value and the mappings go from working to not working accordingly in the same vim session.

Thanks for posting the issue to the mailing list. That was going to be my next step. I'm on the list as well so I'll keep an eye out for your message and post any input I have as necessary.

[StanAngeloff]

So I rooted out the problem. Apparently the way plugins use <Plug> bindings means that their bindings are translated according to langmap.
@ogier

Ah, interesting. In my case langmap is blank, e.g., there's no value for it. I looked for any bundles that might set it up explicitly, but I couldn't find any.

I've traced it down to ForwardBack. There's something going on with:

exec "let map = \"" . escape(a:map, '<') . "\""

Also in my case pumvisible() is always 0 which is very odd. I'd need to carry on poking around for a while to figure this one out.

[ervandew]

I've traced it down to ForwardBack.

Can you temporally remove supertab, then startup vim and post the results of the following commands:

:verbose imap <c-n>
:verbose imap <c-p>

Then with supertab re-added, can you restart vim and run those commands again and post the results.

Also in my case pumvisible() is always 0

Can you also post the result of the following:

:verbose set completeopt?

[StanAngeloff]

Can you temporally remove supertab, then startup vim and post the results of the following commands:

:verbose imap <c-n>
:verbose imap <c-p>

:verbose imap <c-n>
No mapping found
:verbose imap <c-p>
No mapping found

Then with supertab re-added, can you restart vim and run those commands again and post the results.

:verbose imap <c-n>
i  <C-N>         <C-R>=<SNR>48_ForwardBack("n", "<Plug>SuperTabForward")<CR>
        Last set from ~/.vim/bundle/supertab/plugin/supertab.vim
:verbose imap <c-p>
i  <C-P>         <C-R>=<SNR>48_ForwardBack("p", "<Plug>SuperTabBackward")<CR>
        Last set from ~/.vim/bundle/supertab/plugin/supertab.vim

Can you also post the result of the following:

:verbose set completeopt?

:verbose set completeopt?
  completeopt=menu,preview

For tracing purposes, I changed ForwardBack to:

  function! s:ForwardBack(command, map)
    echom 'a:command = ' . a:command
    echom 'a:map = ' . a:map
    exec "let map = \"" . escape(a:map, '<') . "\""
    echom "let map = \"" . escape(a:map, '<') . "\""
    echom 'pumvisible() = ' . pumvisible()
    echom 'map = ' . map
    return pumvisible() ? s:SuperTab(a:command) : map
  endfunction

and on pressing <C-N> the following results in :messages<CR>:

a:command = n
a:map = <Plug>SuperTabForward
let map = "\<Plug>SuperTabForward"
pumvisible() = 0
map = <80><fd>SSuperTabForward

I hope those help, let me know if I can run anything else.

[ervandew]

i <C-N> <C-R>=<SNR>48_ForwardBack("n", "<Plug>SuperTabForward")<CR>

That's odd. Do you have supertab installed in more than one place (you can use :scriptnames to see if supertab shows up more than once)? If not, is supertab loading more than once (throw an echom at the top of supertab.vim after the two conditionals)?

[StanAngeloff]

I'm managing Vim plug-ins using Vundle (.vimrc for reference). I wiped out all existing bundles just in case:

$ rm -R ~/.vim/bundle
$ vim -c 'BundleInstall' -c 'qa!'

This should give me a pretty clean environment to work from. Here's the output of :scriptnames:

:redir >> ~/.vimscriptnames
:scriptnames
:redir END

  1: /usr/share/vim/vimrc
  2: /usr/share/vim/vim73/debian.vim
  3: /usr/share/vim/vim73/syntax/syntax.vim
  4: /usr/share/vim/vim73/syntax/synload.vim
  5: /usr/share/vim/vim73/syntax/syncolor.vim
  6: /usr/share/vim/vim73/filetype.vim
  7: ~/.vimrc
  8: /usr/share/vim/vim73/ftoff.vim
  9: ~/.vim/autoload/pathogen.vim
 10: /usr/share/vim/vim73/syntax/nosyntax.vim
 11: ~/.vim/bundle/mustache.vim/ftdetect/mustache.vim
 12: ~/.vim/bundle/tmux.vim/ftdetect/tmux.vim
 13: ~/.vim/bundle/vim-coffee-script/ftdetect/coffee.vim
 14: ~/.vim/bundle/vim-coffee-script/ftdetect/eco.vim
 15: ~/.vim/bundle/vim-git/ftdetect/git.vim
 16: ~/.vim/bundle/vim-haml/ftdetect/haml.vim
 17: ~/.vim/bundle/vim-handlebars/ftdetect/handlebars.vim
 18: ~/.vim/bundle/vim-javascript/ftdetect/javascript.vim
 19: ~/.vim/bundle/vim-json/ftdetect/json.vim
 20: ~/.vim/bundle/vim-less/ftdetect/less.vim
 21: ~/.vim/bundle/vim-markdown/ftdetect/markdown.vim
 22: ~/.vim/bundle/vim-task/ftdetect/task.vim
 23: ~/.vim/bundle/vim-zend55/colors/vim-zend55.vim
 24: /usr/share/vim/vim73/ftplugin.vim
 25: /usr/share/vim/vim73/indent.vim
 26: ~/.vim/bundle/vundle/autoload/vundle.vim
 27: ~/.vim/bundle/vundle/autoload/vundle/config.vim
 28: ~/.vim/bundle/detectindent/plugin/detectindent.vim
 29: ~/.vim/bundle/csapprox/plugin/CSApprox.vim
 30: ~/.vim/bundle/tabular/plugin/Tabular.vim
 31: ~/.vim/bundle/gitv/plugin/gitv.vim
 32: ~/.vim/bundle/zencoding-vim/plugin/zencoding.vim
 33: ~/.vim/bundle/tagbar/plugin/tagbar.vim
 34: ~/.vim/bundle/tlib_vim/plugin/02tlib.vim
 35: ~/.vim/bundle/vim-snipmate/plugin/snipMate.vim
 36: ~/.vim/bundle/vim-addon-mw-utils/autoload/funcref.vim
 37: ~/.vim/bundle/vim-snipmate/plugin/snipMateInterface.vim
 38: ~/.vim/bundle/vim-task/plugin/task.vim
 39: ~/.vim/bundle/nerdcommenter/plugin/NERD_commenter.vim
 40: ~/.vim/bundle/nerdtree/plugin/NERD_tree.vim
 41: ~/.vim/bundle/nerdtree/nerdtree_plugin/exec_menuitem.vim
 42: ~/.vim/bundle/nerdtree/nerdtree_plugin/fs_menu.vim
 43: ~/.vim/bundle/syntastic/plugin/syntastic.vim
 44: ~/.vim/bundle/gundo.vim/plugin/gundo.vim

Using echom at the top of supertab/plugin/supertab.vim yields two messages. I added:

if exists("loaded_supertab")
  finish
endif
let loaded_supertab = 1

and that seems to fix the issue in question. W00t!

[ervandew]

That's weird that supertab is loaded twice but doesn't show up in :scriptnames at all.

[mkrauskopf]

Hi. I have the same issue as Stan and found this issue. :scriptnames lists supertab exactly once for me. Patch with loaded_supertab check fixed the issue for me as well. Could it be propagated to the mainstream?

[ervandew]

It was added about a month ago: 7ee7f77

[mkrauskopf]

Indeed, thanks. I was using SuperTab-continued. in my Vundle config. Switched to ervandew/supertab.git.

[HealsCodes]

Just to highlight an issue / feature that happens quiet often with vim plugins:
feedkeys() has an optional second parameter called 'mode' which defaults to 'remap'.

In this case your plugin will probably break if you have langmap's active.
If you use 'n' (noremap) as second parameter to feedkeys() then it will ignore the langmap and work for everyone.
I have to resort to this manual patching frequently as I use a langmap to map hjkl navigation to a dvorak layout.

[ervandew]

Yes, for cases where the plugin is able to, feedkeys is handy, but in this case vim is modifying the defined mapping even after it has been defined, so I don't see how feedkeys would be helpful in this case, if that's what you are suggesting.

[HealsCodes]

Indeed you're right since it's already the = that gets mixed up..
In the meantime I had a deeper look at the exact langmap behavior and (just for reference) this will fix it for supertab:

autocmd InsertEnter * let g:saved_langmap=&langmap | set langmap&
autocmd InsertLeave * let langmap=g:saved_langmap

Still not an ideal solution but at least a workaround.

[mknod]

I wanted to let others know that I had this problem and it was caused by 2 system installed plugins that were conflicting with my vundle install. On arch I did a pacman -R vim-ultisnips vim-supertab and after that I was able to happily use supertab again!