Composing blocks checking for new

Fri Nov 2 22:53:07 UTC 2018

On 29Oct2018 12:56, Bastian <bastian-muttuser at t6l.de> 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|python-list at python.org|python-ideas at python.org)
             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 <cs at cskk.id.au>