silver2row / mintty

Automatically exported from code.google.com/p/mintty
GNU General Public License v3.0
0 stars 0 forks source link

Screen resize #354

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
 Resize the window while running vim

What is the expected output? What do you see instead?
 Should become white.

What versions of mintty, Cygwin/MSYS, and Windows are you using?
CYGWIN_NT-6.1-WOW64 leningrad 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin

Is it supposed to be like this? Sorry for inconvenience

Original issue reported on code.google.com by leventd...@gmail.com on 1 Oct 2012 at 4:55

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
This is fixed in Cygwin snapshot 2013-01-11.

Original comment by andy.koppe on 12 Jan 2013 at 8:59