I am using Cygwin's MinTTY. $TERM is xterm-256color.
Following scenario:
Go to insert mode
Press <esc>
Quickly press n (as in, go to next search result)
rather than going to the next match, results in cursor being moved as if I pressed <esc>ja and it doesn't go to normal mode.
What's interesting is that rather than entering insert mode again, it looks like I never left insert mode in the first place.
This leads me to believing that I am pressing keys quick enough that it gets interpreted as an escape sequence of one keypress, which matches some libreadline key binding. Following this logic, it manifests only now because before I've installed vim-rsi, that sequence was unbound and its components got interpreted as separate keypresses.
I can fix the behavior by adding let g:rsi_no_meta = 1 to .vimrc, but this breaks altb in command mode.
I think adding an option whether to include readline keybindings in insert mode would be sufficient. Actually, this is caused by noremap! <M-n> <Down>... not sure what to make of it.
I am using Cygwin's MinTTY.
$TERM
isxterm-256color
.Following scenario:
<esc>
n
(as in, go to next search result)rather than going to the next match, results in cursor being moved as if I pressed
<esc>ja
and it doesn't go to normal mode.What's interesting is that rather than entering insert mode again, it looks like I never left insert mode in the first place.
This leads me to believing that I am pressing keys quick enough that it gets interpreted as an escape sequence of one keypress, which matches some libreadline key binding. Following this logic, it manifests only now because before I've installed
vim-rsi
, that sequence was unbound and its components got interpreted as separate keypresses.I can fix the behavior by adding
let g:rsi_no_meta = 1
to.vimrc
, but this breaks altb in command mode.I think adding an option whether to include readline keybindings in insert mode would be sufficient.Actually, this is caused bynoremap! <M-n> <Down>
... not sure what to make of it.