pseudo multi-threading
Hello. I have been working on trying to achieve a sort of pseudo
multi-threading in mutt. I have managed to make some progress, but it's been
trickier than I would have liked and I was hoping maybe others out there could
help or offer suggestions.
The goal is to be able to compose messages in a separate window, while the
original mutt continues normally in the original window (ie. not waiting for
anything to be returned). Obviously mutt isn't capable of actual
mutli-threading. However, since multiple mutt instances can coexist, this can
sort of be achieved by spawning a new mutt instance to handle each new
composition, that would then quit when the message is finally sent.
I finally figured out that I accomplish this more-or-less from within mutt by
setting the editor variable to be the following:
set editor="~/bin/mutt_bgrun rxvt -e 'mutt -F ~/.mutt/muttrc.ext -H'"
where "mutt_bgrun" is the great script (written by Gary A. Johnson) to load
files in the background from within mutt [0]. The editor variable is expanded
and passed a template file (with the header and quoted messages if applicable).
In this case, mutt_bgrun is told to open an rxvt in the background executing
mutt, which is then itself passed the template file. In order to get around the
infinite regress that would occur, the new mutt is given a different muttrc file
with a different editor variable:
set editor="/usr/bin/emacs -nw"
Now what happens is that when I go to compose a new message, the message editor
is opened in the new mutt in the new rxvt. The original mutt thinks the editor
returns an unedited message, and aborts sending with the following mutt variable
set:
set abort_unmodified=yes
Once I'm done editing in the new editor (emacs) in the new mutt, I am returned
to the new mutt's compose environment to polish off sending the email (adding
attachments, cc, etc.), and then the new mutt quits when the message is finally
sent, killing it's host rxvt.
This setup actually works quite well, except that there is one big issue:
forwarding doesn't work. First of all, when forwarding, the original mutt
doesn't abort sending (presumably since it doesn't see the message as being
unmodified) and jumps back to the compose environment, which you then must quit
out of to avoid sending the message twice. Second, forwarding mime attachments
doesn't work since the attachments are not passed to the secondary spawned mutt.
Unfortunately I can't figure out how to get around these issue.
My question to all the mutt users out there is, can anyone think of a way to
polish off the technique I've outlined above by figuring out how to get around
the issue of forwarding? I personally don't see how it can be done, but it sure
would be nice. Also, can anyone think of any adverse side effects to my method
that I haven't seen yet? Maybe people know alternate/better ways to achieve the
same thing. If so, please pass them along. I'm putting together a how-to page
on this, so I'd be happy to include them (with appropriate citing and links).
To the developers, maybe there's an easy way to modify mutt to accomplish what
I'm trying to do. I think a lot of people would be interested in a pseudo
multi-threading functionality similar to what I've achieved. Maybe all this
trickery could be circumvented with a new variable, something meta to "editor",
like "compose" command that could just be passed all of the files to be sent,
with the first one being the body of the message. I need to think about it more
to figure out what the right answer would be. I am NOT suggest adding true
mutli-threading, since I just don't think that's a good idea. But a way to
spawn a new mutt for composing, similar to what I've achieved, would be, I
think, the right way to go, and maybe not that difficult to accomplish. In any
event, thanks for creating such a great and flexible mailer.
jamie.
links:
[0] http://www.spocom.com/users/gjohnson/mutt/#myfiles