shawn a. <[EMAIL PROTECTED]> wrote:
>
> startup mutt, type a !vim<enter> (it also works when I hit a m), when
> vim starts up resize the XTerm's window for a bit, this Is where the
> bug happens for me -- mutt's interface overtakes vim but vim is still
> running.  its like vim and mutt are both trying to be the head app, it
> is pretty weird.

This is a signal-handling bug in your shell.  When Mutt launches the
editor, it is very careful to set up the signal handlers for all signals
that could come in.  However, the process tree goes something like this:

    mutt
        sh -c 'vim'
            vim

So, the direct child of Mutt is sh, and the editor runs as a child of sh.

What happens is that the intermediate 'sh' messes up the signal
handlers.  It shouldn't do that, and most shells don't, but there are
apparently some buggy versions that do.

When you resize your xterm, a SIGWINCH signal is sent to all the
processes running in that window.  That means Mutt, sh, and Vim all get
the signal.  Mutt and Vim handle it properly.  Sh should ignore it, but
it fails, and instead, sh exits completely, leaving vim still running as
an orphaned process, where Mutt can't see it anymore.  Mutt thinks that
the editor has finished, so it resumes processing, but the editor is
still running, and they fight over the terminal.


So... What to do?  Well, use a different shell.  Upgrade your /bin/sh to
a more recent version.  Or, if you have another shell to use, that is
/bin/sh compatible, use that, by re-configuring Mutt with the
--with-exec-shell option.  Try /bin/ksh or /bin/bash instead.

As a last resort, you might try

    set editor="exec vim"

This will cause the sh process to replace itself with the editor.  That
gets the buggy shell out of the way, but since the shell is going to be
used to launch other commands from Mutt, too, you would be better off
with a non-buggy shell instead.

-- 
David DeSimone   | "The doctrine of human equality reposes on this:
[EMAIL PROTECTED]   |  that there is no man really clever who has not
Hewlett-Packard  |  found that he is stupid." -- Gilbert K. Chesterson
UX WTEC Engineer |    PGP: 5B 47 34 9F 3B 9A B0 0D  AB A6 15 F1 BB BE 8C 44

Reply via email to