<<< Date Index >>>     <<< Thread Index >>>

[PATCH] fixes for 915 and 1907

Hi,

  while discussing [1] bug#1907 (Window resize mishandling on suspend
  case), its possible relation to bug#915 (window resize is not handled
  correctly in one situation) was brought up. finally, they seemed to be
  two different issues.

  Paul Walker sent a straightforward patch for #1907. I'm attaching the
  whole message (is not in the archives).

  I found a fix for 915, too, which consists in changing the position of
  a two-line block. Patch attached, full message at [2].

  And that's all for now.

  [1] I was going to put an URL here, but I can't find the thread in the
      list archives. (!)

  [2] http://does-not-exist.org/mail-archives/mutt-dev/msg01380.html

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The most common form of marriage proposal: "YOU'RE WHAT!?"
--- Begin Message --- 
On Fri, Jun 25, 2004 at 07:55:38PM -0400, Thomas Dickey wrote:

> I'd be inclined to say the problem is in mutt (common factor).  But it
> could be a similar bug but not the same one.  Seeing if mutt's sigwinch
> handler is blocked or not seems to be the real issue.  Just reading the
> code, I don't see the problem though.

Regarding 1907, the problem seems to be that if we're suspended and a
SIGWINCH occurs, it just gets dropped - we don't get told about it. I think
this makes sense, but I don't actually have anything going into detail about
the signals system, and the man pages aren't really enough for this. Some
signals are obviously still propagated when suspended, but are all of them?

A probably-not-correct-but-sufficient patch is attached, which seems to
correct the problem for me - could people check this? A correct patch would
probably store the window size before suspend and verify on resume, but this
one has the same effect. I'll look into it later, along with trying to find
out the behaviour of signals with suspended processes. Could be fun.

Alan - the patch is against CVS, but it doesn't look like the file's been
changed for ages, so it might well apply against the Red Hat 1.4 as well.
I'd only use it if you're actually doing the suspend-resize thing a lot,
though, until it gets fixed properly. (Possibly by someone else!)

No idea yet why the problem would occur when reading a big mailbox.

-- 
Paul

The problem I have with making an intelligent statement is that some
people then think that it's not an isolated occurrance.
 -- Simon Travaglia

--- mutt/signal.c       Wed Dec 11 22:08:57 2002
+++ mutt.resize/signal.c        Sat Jun 26 14:06:04 2004
@@ -75,6 +75,11 @@
       if (!IsEndwin)
        refresh ();
       mutt_curs_set (-1);
+#if defined (USE_SLANG_CURSES) || defined (HAVE_RESIZETERM)
+      /* We don't receive SIGWINCH when suspended; however, no harm is done by
+       * just assuming we received one, and triggering the 'resize' anyway. */
+      SigWinch = 1;
+#endif
       break;
 
 #if defined (USE_SLANG_CURSES) || defined (HAVE_RESIZETERM)

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- curs_main.c.orig    2004-06-28 04:57:39.000000000 +0200
+++ curs_main.c 2004-06-28 04:57:49.000000000 +0200
@@ -576,10 +576,6 @@
        move (menu->current - menu->top + menu->offset, COLS - 1);
       mutt_refresh ();
 
-      op = km_dokey (MENU_MAIN);
-
-      dprint(4, (debugfile, "mutt_index_menu[%d]: Got op %d\n", __LINE__, op));
-
 #if defined (USE_SLANG_CURSES) || defined (HAVE_RESIZETERM)
       if (SigWinch)
       {
@@ -598,6 +594,10 @@
       }
 #endif
 
+      op = km_dokey (MENU_MAIN);
+
+      dprint(4, (debugfile, "mutt_index_menu[%d]: Got op %d\n", __LINE__, op));
+
       if (op == -1)
        continue; /* either user abort or timeout */