On 2016-09-02, Felipe Vieira wrote: > Dear Gary, > > you are absolutely right. Vim is not the problem. > > I did two changes at the same time and indeed tried the vim -u none > but maybe did not catch the error. > > Finally what causes the error is: > > inoremap <esc> <Nop> > > no my vimrc. From http://vimdoc.sourceforge.net/htmldoc/map.html: > > *<Nop>* > A easier way to get a mapping that doesn't produce anything, is to use > "<Nop>". > > Anyways this is not the expected behavior. Is there some complexity > here that I'm not capturing? In theory I'm disabling the <esc> key and > that's all. Why is it interfering with m arrow keys and the del key?
The escape character alone in insert mode changes the mode to normal. The escape character may also begin an "escape sequence" when it is followed "immediately" by certain other characters. Vim determines whether an escape character is intended to be interpreted alone or as the beginning of an escape sequence by waiting only so long for the next character following the escape. If the next character arrives after some time limit, the escape is processed as a single escape and subsequent characters are processed as themselves rather than part of an escape sequence. In your case, it appears that the characters following the escape in the escape sequences for the arrow and delete keys are arriving after that time limit. That time limit is set by the 'ttimeoutlen' option, or by the 'timeoutlen' option if the value of 'ttimeoutlen' is negative. See ":help 'ttimeoutlen'". This timeout defaults to 1 second, which should be plenty of time for a terminal emulator such as mintty to send an escape sequence. What do you see when you execute this? :verbose set timeoutlen? ttimeoutlen? Regards, Gary -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple