3

I've been trying to get Shift+Tab or <S-Tab> to work in VIM and I can't figure it out.

I read this document, but the remap solution only works for normal mode (because if I press Shift+Tab, VIM reads the literal escape ^] in the Shift+Tab escape sequence ^]]Z, which causes VIM to leave insert mode!), and the set t_kb="<stuff>" also only works for normal mode on my vim. You can test the latter option by entering:

exe 'set t_kB=' . nr2char(27) . '[Z'
nmap <S-Tab> ihello world!
imap <S-Tab> hello world!

...then try pressing Shift+Tab. The first remap does work, but the second remap is ignored. I also tried the xmodmap from the terminal, then entering VIM, and still I have the same issue.

Can anything be done here?

7
  • 1
    Hmm. Works just fine for me in two different environments. If it helps, in one env I see t_kB <S-Tab> ^[[Z when I do set t_kB? (the ^[ is control character equiv. to ESC). In the other env. I get "Key code not set" (!) What do you see? And what do you see when you enter Ctrl-V then Shift-Tab while in Insert mode?
    – B Layer
    Feb 3, 2018 at 10:40
  • I see the following: t_kB <S-Tab> ^[[Z. Despite this the ^[ seems to be interpreted literally from insert mode. I actually figured out a super hacky way to use Shift+Tab to navigate the popup menu in Insert mode by creating a normal mode remap for [Z. May post it later, but hopefully someone can figure out the main problem first.
    – Luke Davis
    Feb 3, 2018 at 11:04
  • 4
    If it's working in normal mode then that suggests that it is not a system-level cause, anything to do with key codes, terminal intercepting, and so on. Meaning the problem should be purely vim related (configuration, conflicting plugin, etc.). Have you tried with empty configuration (vim -u NONE filename)? BTW, never use nmap, imap, etc. unless you are doing so deliberately and for a specific reason. Instead use nnoremap, inoremap, etc. (That's not likely to be the cause in this case but better safe than sorry.)
    – B Layer
    Feb 4, 2018 at 15:17
  • 1
    Yeah, I know...normal works, insert doesn't...my comment wouldn't make sense if I thought otherwise.
    – B Layer
    Feb 5, 2018 at 8:19
  • My bad; I'm dumb and was tired. Is there any chance -u NONE disables all mappings, even ones explicitly declared after the fact? I tried doing the S-Tab maps and then as a test, creating the map nmap <Space> ihello world!, but instead the bell rings/VIM ignores my command. So can't seem to test it this way. Typing :map <Space> verifies the mapping was created.
    – Luke Davis
    Feb 5, 2018 at 17:57

2 Answers 2

3

Thanks to @B Layer for their help. Turns out that all escape-prefixed keycodes (e.g. forward-delete, shift-tab, scroll-wheel-up, scroll-wheel-down) will fail for the mode in question if there is any mapping of the escape key. That is: most (all?) of the keyboard events in :help terminal-key-codes will fail. In my case, I had inoremap <Esc> <Esc><other stuff> in my .vimrc.

So the answer is: if you want to use these key-codes, never, ever map the escape key.

You also need to make sure the &esckeys option is turned on with the following:

set esckeys

but this was not the issue in my case.

0

I had the same thing. Shift tab worked fine in other modes but not in insert mode. It does get detected, because Supertab reacts in the statusline. This overwrites it fine for me:

inoremap <Esc>[Z <Esc> :call whatever

Similar but different from a solution in the document mentioned in the main question. It does mess with the shift tab in supertab now.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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