Shift-tab key mapping broken in betas
Hello, and thank you for all of the time and effort you put into iTerm2. Seriously, thank you so much.
I only recently noticed the below issue happening with the beta builds. The 3.3 series and before work as expected. The gist is that in Vim, when in insert mode, I have some custom key bindings for the tab and shift-tab keys. When those are pressed the bindings will trigger Vim's built-in completion menu to appear. Continuing to hit tab will cycle forward (down) through the options, and shift-tab will cycle backward (up) through them. The problem is with the shift-tab key - it no longer works and instead a literal <95> is inserted into the document. Maybe this is some kind of control code? I'm not sure. Below is all of the info. I'm happy to get whatever other info you need to help diagnose. Thank you!
- iTerm2 version: 3.4.0beta11
- OS version: 10.15.7
- Attach ~/Library/Preferences/com.googlecode.iterm2.plist: com.googlecode.iterm2.plist
- Debug log: debuglog.txt
- Screencap video: shift-tab-bug
Detailed steps to reproduce the problem:
- Open a file in Vim, using the
--cleanoption. - Source in a file that defines a custom function and two key mappings:
- An insert-mode mapping for
<tab>which either does a normal tab, or starts the completion menu. If the menu is already open, cycle forward through completion options. - An insert-mode mapping for
<s-tab(Shift-Tab) which sends the<C-P>(Control-P) keys, which should cycles backward through the list of completions
- An insert-mode mapping for
- In Vim, move into insert mode, type the first few characters of a word that will have several completion matches.
- Trigger completion menu with
<tab>, and cycle forward through a few options. - Hit
<s-tab>which should cycle backward through the options.
What happened:
At step 5, the completion menu closed and the literal characters <95> were inserted into the document.
What should have happened:
At step 5 we should have gone backward (or, "up") through the completion options.