Closed GoogleCodeExporter closed 9 years ago
I don't know. You haven't really said what the problem is, nor how to reproduce
it. Also, you could check in rxvt or xterm to see whether it's vim issue.
Original comment by andy.koppe
on 1 Oct 2012 at 7:14
Problem is when vim is running if you resize the mintty, the whole screen
becomes white. If I press a key, it comes back to normal. I'll try with xterm
also.
Original comment by leventd...@gmail.com
on 1 Oct 2012 at 7:23
I tried with xterm. the screen doesn't refresh until I pressed a key. I tried
with mutt also. I think there is a problem with application mode.
Original comment by leventd...@gmail.com
on 1 Oct 2012 at 7:42
Thanks. I've reproduced the delayed refresh too, with vim, mutt and mined, in
both mintty and xterm. I'm afraid I don't know what's going on there, but it
doesn't look like a mintty issue as it's the same in xterm. Can you report this
to the Cygwin mailing list? My guess is that the SIGWINCH signal for indicating
terminal size changes isn't being delivered immediately.
I didn't see the white screen, so that might be specific to your setup. Maybe
it's the default background colour of that rather nice-looking vim
configuration you've got there.
Original comment by andy.koppe
on 2 Oct 2012 at 11:50
Actually, cygwin mailing list is not friendly like this project. So I prefer
not to report. Thanks for your help.
Original comment by leventd...@gmail.com
on 2 Oct 2012 at 2:34
Andy, I emailed you about this issue in August. I've done some investigating
sporadically, and come up with the following conclusions:
It occurs in ncurses based applications
It appears to be an issue in ncurses, but the problem can be resolved by downgrading cygwin1.dll to 1.7.15 (but NOT downgrading ncurses)
SIGWINCH appears to be generated immediately on window size change (also on some other window events from my testing experience)
SIGWINCH handler (in mutt, which was my test vehicle) processes the interrupt immediately, doing so on top of a (timeout blocked) ncurses call to getch()
getch() does NOT immediately return KEY_RESIZE; instead, it either waits until the timeout expires and then returns KEY_RESIZE, or it returns ERR and the subsequent call to getch returns KEY_RESIZE
I can only speculate that in 1.7.15, cygwin1.dll did/allowed more than raise
SIGWINCH on a window resize. Perhaps it raised a second signal that caused the
timeout blocked getch() to abort. Or might have sent a character that acted as
a NOOP (it couldn't have been a KEY_RESIZE because that is caught in a tight
loop by mutt and would not have allowed the flag set by the SIGWINCH handler to
be detected.
Original comment by as...@netmeeba.com
on 16 Nov 2012 at 1:44
Hi Ashok, thanks very much for those details. I think this needs to be reported
to the Cygwin mailing list, as I don't think there's much that mintty can do
about it. I keep on meaning to investigate and do that, but I'm not getting
round to it.
Btw, the issue doesn't appear to be specific to ncurses, because I've also
encountered it with the 'mined' editor, which doesn't use ncurses. On the other
hand, emacs appears to be unaffected, as was a small test case that I tried a
while ago.
Original comment by andy.koppe
on 16 Nov 2012 at 1:56
Issus posted to Cygwin mailing at
http://cygwin.com/ml/cygwin/2012-11/msg00119.html. Thanks Ashok! Closing this
now.
Original comment by andy.koppe
on 17 Nov 2012 at 6:09
This is fixed in Cygwin snapshot 2013-01-11.
Original comment by andy.koppe
on 12 Jan 2013 at 8:59
Original issue reported on code.google.com by
leventd...@gmail.com
on 1 Oct 2012 at 4:55Attachments: