Terminal resize problem after editor is called

[pdmef]

Mutt (ncurses?) doesn't seem to properly catch up upon terminal resize when the editor is involved. I have two scenarios where I can exactly reproduce it on OS X (xterm in Apple's X11 and Terminal.app) and FreeBSD (xorg's xterm). I use mutt hg tip with ncursesw 5.6 in all 3 cases.

Scenario 1:

• In the index, edit a message, quit without saving.
• Enlarge the screen just a little bit.
• Repeat step 1).
• Now the index is drawn as if the terminal wasn't resized in step 2.

Scenario 2:

• From the index, start composing a message, edit message in the editor.
• Leave the compose menu without postponing and sending.
• Enlarge the terminal just a little bit.
• Repeat step 1)
• Now the compose menu is drawn as if the terminal wasn't resized in step 3).
• When comming back to the index, it's also drawn as if no resize happened.

In both cases, when resizing the terminal from the index, mutt recognizes the new size and everything seems to work fine again. However, once the editor was invoked either way, things are broken afterwards again.

The only way to make mutt usable again is to exit it and restart. This is especially true when the terminal is made smaller since it completely messes up everything.

I've put some debug printing in and it turns out that LINES and COLS are really the narrower old sizes afterwards, so mutt does everything right with wrong values reported by curses.

Especially the fact that mutt gets the original size (just when mutt was started) over and over again if endwin() is called in between makes we wonder whether it's curses having a problem to catch up upon resizing or if it's mutt. But I'm by no means a curses expert.

[Vincent Lefevre]

On 2007-09-19 08:36:15 -0000, Mutt wrote:
> #2960: Terminal resize problem after editor is called
> 
>  Mutt (ncurses?) doesn't seem to properly catch up upon terminal resize
>  when the editor is involved. I have two scenarios where I can exactly
>  reproduce it on OS X (xterm in Apple's X11 and Terminal.app) and FreeBSD
>  (xorg's xterm). I use mutt hg tip with ncursesw 5.6 in all 3 cases.

Dup of bug 2207?

[Rocco Rutte]

Hi,

* Mutt [07-09-20 10:47:10 -0000] wrote:
>#2960: Terminal resize problem after editor is called

>Comment (by Vincent Lefevre):

> {{{
> On 2007-09-19 08:36:15 -0000, Mutt wrote:
> > #2960: Terminal resize problem after editor is called

> >  Mutt (ncurses?) doesn't seem to properly catch up upon terminal resize
> >  when the editor is involved. I have two scenarios where I can exactly
> >  reproduce it on OS X (xterm in Apple's X11 and Terminal.app) and FreeBSD
> >  (xorg's xterm). I use mutt hg tip with ncursesw 5.6 in all 3 cases.

> Dup of bug 2207?

I have the same issue as #2207 here, too (on OS X). The difference 
between #2207 and is #2960 is that the former happens while in the 
editor while for the latter, it only matters that the editor is called 
at all; resizing can be done in mutt.

So I'm not really sure if they're the same, I think they likely are.

   bye, Rocco

[louipc]

A similar problem is being experienced here http://bugs.archlinux.org/task/10689 I can't actually reproduce any of them though.

[brendan]

Now that #2207 is fixed (in [be7e07963099]), can you reproduce? I can't.

[pdmef]

Yes, I can reproduce it under these environments:

• OS X: xterm+Terminal.app with ncursesw 5.6.20061217
• Debian: xterm with ncurses 5.5.20060422

I'll see if I can put some debug code in to see what happens.

[brendan]

On IRC, pdmef reports that the TIOCGWINSZ ioctl succeeds, and that resizeterm returns 0, after both edits.

[brendan]

I've just tried on OSX in Terminal.app and xterm

• System: Darwin 9.3.0 (i386)
• ncurses: ncurses 5.4.20041023 (compiled with 5.4) (fink libncursesw)

I still cannot reproduce either scenario.

[pdmef]

I've patched the source as follows:

diff --git a/resize.c b/resize.c
--- a/resize.c
+++ b/resize.c
@@ -54,7 +54,10 @@ void mutt_resize_screen (void)
     {
       SLtt_Screen_Rows = w.ws_row;
       SLtt_Screen_Cols = w.ws_col;
+      dprint(1,(debugfile,"resize: %d,%d\n", SLtt_Screen_Rows, SLtt_Screen_Cols));
     }
+    else
+      dprint(1,(debugfile,"resize: ioctl() failed\n"));
     close (fd);
   }
   if (SLtt_Screen_Rows <= 0)
@@ -80,6 +83,9 @@ void mutt_resize_screen (void)
   stdscr = newwin (0, 0, 0, 0);
   keypad (stdscr, TRUE);
 #else
-  resizeterm (SLtt_Screen_Rows, SLtt_Screen_Cols);
+  {
+    int rc = resizeterm (SLtt_Screen_Rows, SLtt_Screen_Cols);
+    dprint(1,(debugfile,"resize: resizeterm(%d,%d) = %d\n", SLtt_Screen_Rows, SLtt_Screen_Cols, rc));
+  }
 #endif
 }

and run mutt:

$ mutt -nF /dev/null -e 'set editor=true' -f ...

I...

• go to a message, hit e, everything is fine.
• enlarge the terminal, everything is fine.
• hit e, mutt redraws everything as if I didn't change the size.

I can repeat steps 2 and 3 as often as I want, after 3 it always redraws the screen using the size as it was when I started mutt. The debug log shows these lines:

resize: 35,98
resize: resizeterm(35,98) = 0
resize: 50,135
resize: resizeterm(50,135) = 0
resize: 50,135
resize: resizeterm(50,135) = 0
resize: 60,163
resize: resizeterm(60,163) = 0
resize: 60,163
resize: resizeterm(60,163) = 0
resize: 73,189
resize: resizeterm(73,189) = 0
resize: 73,189
resize: resizeterm(73,189) = 0
resize: 78,213
resize: resizeterm(78,213) = 0
resize: 78,213
resize: resizeterm(78,213) = 0

[pdmef]

Using setenv() to set the values for $LINES and $COLS from SLtt_Screen_Rows and SLtt_Screen_Cols works but it doesn't feel quite right...

[brendan]

I'm willing to accept the setenv hack, but I don't think this bug should remain as a 1.6 blocker -- it doesn't look like it's really a mutt bug and it seems to be a pretty rare occurence.