Re: pseudo multi-threading
On 2006-03-23, Jamie Rollins <jrollins@xxxxxxxxx> wrote:
> 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).
[...]
> 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).
I wrote another script a while back, mutt_bgread, that allows one to
read messages in a separate mutt instance running in an xterm
window. I did this so that I could read long messages, such as
newsletters, at my leisure while still being able to use mutt for
reading and sending other messages.
You could get the behavior you want by using the mutt_bgread script
to read the message, then reply or forward from the second mutt
instance. The script copies the entire message, so the second mutt
has access to all the attachments.
The core of the script is this line:
xterm -e sh -c 'eval `resize`; exec mutt -R -f '"$tmpfile"' -e "set
pager_index_lines=0;exec display-message"'
Note the "exec display-message" command. You could change this to
"exec forward-message" or to "view-attachments", depending on how
you forward messages, to start the forwarding process immediately.
I haven't posted this script to my web page because I haven't heard
of much demand for such a script and I didn't want to take the time
to make sure that it would run on a variety of systems. It is
fairly short, so I have attached it here.
As for adverse side effects: I never reply to messages from the
mutt_bgread script because the 'r' flag won't get set in the
original mailbox.
HTH,
Gary
--
Gary Johnson | Agilent Technologies
garyjohn@xxxxxxxxxxxxxxx | Wireless Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA
#!/bin/sh
# @(#) mutt_bgread $Revision: 1.3 $
# mutt_bgread - read a message in the background using another instance of
mutt
# Copyright (C) 2002-2006 Gary A. Johnson
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
# SYNOPSIS
# mutt_bgread [file]
#
# DESCRIPTION
# mutt_bgread is intended to be launched from one of the following
# macros.
#
# macro index B ":unset wait_key\n|mutt_bgread\n:set wait_key\n"
"display a message in a new xterm"
# macro pager B ":unset wait_key\n|mutt_bgread\n:set wait_key\n"
"display a message in a new xterm"
#
# AUTHOR
# Gary A. Johnson
# <garyjohn@xxxxxxxxxxxxxxx>
prog=${0##*/}
# Create a temporary directory for the temporary file.
#
# This is more secure than creating a temporary file in an existing
# directory.
tmpdir=/tmp/$LOGNAME$$
umask 077
mkdir "$tmpdir" || exit 1
tmpfile="$tmpdir/mail"
cat "$@" > "$tmpfile"
# Run mutt in a new xterm in the background and delete the temporary
# files when done.
# The "eval `resize`" is necessary because the xterm will be the default
# size, yet it will have the LINES and COLUMNS values from its parent
# xterm.
(
xterm -e sh -c 'eval `resize`; exec mutt -R -f '"$tmpfile"' -e "set
pager_index_lines=0;exec display-message"'
rm -f "$tmpfile"
rmdir "$tmpdir"
) &