On 29Oct2018 12:56, Bastian <[email protected]> wrote:
I'm sure the one or the other of you also faced the problem that mutt
enters conditions during which it does not check for new mails anymore.
These are (for me):
- viewing email (display-message)
- composing (new/reply)
Sometimes it happens, that I get distracted and forget mutt in those
conditions or e.g. composing just takes a long time.
As I rely on mutt to check for new mails and then send a bell to its
terminal, it happens that I miss new incoming (urgent) mails. The reason
simply is, that mutt waits/sleeps until the compose editor returns. Or
perhaps checking for new mails is only active on the index view.
Erik has suggested using separate tools for issuing the alerts.
My alerts are issued by my mail filing system, which processes all new
email messages. For example, my inbound rules have this:
!me . to,cc:(ME|[email protected]|[email protected])
subject:/pep.*499
which says to issuean alert (the "!" leading character) and file the
message in my "me" folder (my "priority inbox", for want of a term).
I know, this is my fault. I should be more attentive, but I think I read
about an integration into a terminal multiplexer (screen or tmux). The
idea was, that mutt opens a new window with the compose editor. Thus,
the main mutt instance continues to run in the index-view and will be
able to check for new mails.
That may have been me. (Discussion of the mode you suggest some
paragraphs down...)
My composition mode always opens the composition in a new tmux session
(or screen, back when I was using screen). So looking at my current tmux
sessions:
[~/hg/css-vt(hg:venti)]fleet*> tm
1 ADZAPPER: 1 windows (created Sun Oct 21 13:07:31 2018) [178x103]
2 GETMAIL: 1 windows (created Sun Oct 21 13:07:32 2018) [178x19]
3 HAPROXY: 1 windows (created Sun Oct 21 13:07:32 2018) [80x24]
4 ITUNES_DL: 1 windows (created Sun Oct 21 19:51:51 2018) [178x19] (attached)
5 MACPORTS: 1 windows (created Sun Oct 21 13:07:32 2018) [80x24]
6 MAILFILER: 1 windows (created Sun Oct 21 13:07:32 2018) [178x19]
7 MONITOR_ROUTES: 1 windows (created Sun Oct 21 13:07:32 2018) [80x24]
8 NOTMUCH: 1 windows (created Sun Oct 21 13:07:32 2018) [80x24]
9 PORTFWD: 1 windows (created Sun Oct 21 13:07:32 2018) [178x24]
10 POSTFIX: 1 windows (created Sun Oct 21 13:07:32 2018) [80x24]
11 RRDPOLL: 1 windows (created Sun Oct 21 13:07:32 2018) [80x24]
12 TAIL_MAILDB: 1 windows (created Sun Oct 21 13:07:33 2018) [80x24]
13 UNBOUND: 1 windows (created Sun Oct 21 13:07:33 2018) [178x103]
14 VENTI: 1 windows (created Sun Oct 21 13:07:33 2018) [80x24]
15 mutt-03nov2018-08_37-Re__Composing_blocks_checking_for_new: 1 windows
(created Sat Nov 3 08:37:01 2018) [178x103] (attached)
See session 15? That's this message I'm editing right now (this
message).
I really need to write this up.
Now, my core reason for the tmux session is that if a message is going
to be quite involved I can detach from it and return to mutt, and
reattach later.
In particular, my mutt is, initially, still blocked in compose mode
until I detach from the tmux session (or complete the email and send
it).
For you you want mutt to return monitoring your email immediately. That
would currently imply starting the compose mode asynchronously (totally
doable with my approach, BTW). Perhaps by kicking off the session
detached, and opening a new terminal window on the session, thus
effectively opening a new terminal window for the composition.
First, a description of how the tmuxxing is done. Then some digging into
how to turn that into a "open a distinct compose window" mode.
The tmux session is done thus:
set editor=muttedit
and muttedit is here:
https://bitbucket.org/cameron_simpson/css/src/tip/biGn/muttedit
Because I only want this for reply, normally mutt's editor=$EDITOR, and
I turn this on with a macro for the "g" (group-reply) command.
Mechanically, muttedit is invoked as the editor for the message, and
because it is separate, it needs to include the headers:
set edit_headers=yes
Because this needs to happen seamlessly, I have:
set autoedit=yes
As an editor, it is handed mutt's temporary edit file. I takes a _copy_
of that file, devises a new session name based on the message subject,
and dispatched a tmux session (or screen if there's no tmux) running:
mutt -e 'set editor=vim-flowed' -e 'unset signature' -H "$filename"
So there's you standalone mutt editing a new message.
What about the original mutt? When you (a) detach from the tmux session
_or_ (b) complete the standalone mutt and send the message, the original
mutt sees that as exiting the original editor. When you exit mutt's
compose editor without edits, it silently returns. And because the
original edit file is untouched (the sub-mutt makes a copy ), this
always happens.
Now, how to pop up a new compose window and instantly return?
Basicly you'd have muttedit copy the file to a temp file, then invoke a
terminal programme in the background running the compose-mail mutt and
the main mutt returns immediately to the index view (or whatever).
[...hacks...]
Ok, now muttedit accepts a -w option or notices the $MUTTEDIT_WINDOWPROG
environment variable. If present, it opens the composing mutt in a
distinct window (in a tmux session in case of disaster).
$MUTTEDIT_WINDOWPROG need to be a command prefix which accepts a command
and arguments. For example:
xterm -e
Note: _not_ that must accept distinct command line strings. xterm's -e
option runs the command which follows it, which will be mutt and some
options. If your terminal programme only accepts a shell command string
you'll need a small wrapper script.
Please see if this addresses your needs (or doesn't work).
Cheers,
Cameron Simpson <[email protected]>
