I have observed an issue in vim and mutt as of August 2012, which has
persisted to now. From conversations with some other cygwin users, the issue
may not be strictly related to ncurses based applications (mined apparently
suffers similarly), but my experience is limited to those.
In mutt, the (.muttrc) timeout parameter defines how long mutt waits for a
keystroke before timing out (at which point it does housekeeping that includes
IMAP polling and window redraw (due to the SIGNWINCH). I have not
investigated the vim code, but the observed behaviour is that it blocks with
the window not redrawn until a new keystroke is detected.
When resizing a mintty (apparently also xterm) window, an ncurses application
immediately received a SIGWINCH interrupt. This typically occurs while the
interactive thread is blocked in a timeout-limited call to getch(). What
appears to be happening is that the KEY_RESIZE character that is inserted into
the input queue does not immediately cause the getch() call to return.
Instead, the timeout expires and then either
a) KEY_RESIZE gets returned on the call that timed out
b) ERR is returned and a subsequent call immediately returns KEY_RESIZE
I'm guessing that with cygwin1.dll 1.7.15, something was causing the blocked
getch() to return immediately. Whether it was another signal, some dummy
insertion into the input queue, or something else, I don't know. It seems to
me that this be considered an ncurses issue, but the problem goes away by
downgrading just cygwin1.dll. From a superficial review of the ncurses
source, it would seem that getch() is blocked in select(). This suggests that
cygwin 1.7.15 was pushing some character into the input file descriptor that
cygwin 1.7.16 onward are not doing.
--
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
