Composing blocks checking for new

[Bastian]

Hi all,

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.

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.

Before starting on it all on my own, I'd like to ask here, if you are
familiar with this and if there is a configuration I might should have
a look at. In the end, I'd like to contribute a wiki page which explains
all that.


Thanks,

[Erik Christiansen]

Post by Bastian
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.

Or, perhaps, one mutt instance, but an external mail arrival monitor?
E.g.:

asmail - AfterStep mail monitor
biff - a mail notification tool
coolmail - Mail notifier with 3d graphics
gnubiff - mail notification program for GNOME (and others)
newmail - Notificator for incoming mail
xbuffy - monitor mailboxes and/or newsgroups
xlbiff - X Literate Biff. Displays From and Subject lines of your new mail

and maybe:

mail-notification - mail notification in system tray
mailcheck - Check multiple mailboxes/maildirs for mail

I used xbiff 25 yrs ago, on Solaris. One or more of the above might be
similar ... or better, e.g. xlbiff.

Erik

[Cameron Simpson]

Post by Bastian
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.
- 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-***@python.org|python-***@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).

Post by Bastian
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 <***@cskk.id.au>

[Cameron Simpson]

Post by Cameron Simpson
set editor=muttedit
https://bitbucket.org/cameron_simpson/css/src/tip/biGn/muttedit

Of course, that should be:

https://bitbucket.org/cameron_simpson/css/src/tip/bin/muttedit

Sorry,
Cameron Simpson <***@cskk.id.au>

[Cameron Simpson]

Post by Cameron Simpson

Post by Cameron Simpson
set editor=muttedit
https://bitbucket.org/cameron_simpson/css/src/tip/biGn/muttedit

https://bitbucket.org/cameron_simpson/css/src/tip/bin/muttedit

Updated script a little: streamlines the tmux session setup versus the
window programme, cleans up the temp file.

Cheers,
Cameron Simpson <***@cskk.id.au>

[Kevin J. McCarthy]

My composition mode always opens the composition in a new tmux session (or
screen

Thank you for the detailed write up. I always enjoy reading these kinds
of posts: nuggets of wisdom from long-time users.

mutt -e 'set editor=vim-flowed' -e 'unset signature' -H "$filename"

Instead of "-e 'unset signature'", you may want to try "-e 'set
resume_draft_files'" which turns off even more undesired processing,
like user-defined headers.

[Cameron Simpson]

Post by Kevin J. McCarthy

My composition mode always opens the composition in a new tmux session (or
screen

Thank you for the detailed write up. I always enjoy reading these kinds
of posts: nuggets of wisdom from long-time users.

Thanks.

Post by Kevin J. McCarthy

mutt -e 'set editor=vim-flowed' -e 'unset signature' -H "$filename"

Instead of "-e 'unset signature'", you may want to try "-e 'set
resume_draft_files'" which turns off even more undesired processing,
like user-defined headers.

Wayne Campbell: So, do you... come to Milwaukee often?
Alice Cooper: Well, I'm a regular visitor here, but Milwaukee has
certainly had its share of visitors. The French missionaries and
explorers were coming here as early as the late 1600s to trade with the
Native Americans.
Pete: In fact, isn't "Milwaukee" an Indian name?
Cooper: Yes, Pete, it is. Actually it's pronounced "mill-e-wah-que,"
which is Algonquin for, "the good land."
Wayne: I was not aware of that.

I see that my local copy of the 1.9.4 manual has 360 entries in section
3; it looks like I have some revising to do.

Thanks!

Cheers,
Cameron Simpson <***@cskk.id.au>

[Cameron Simpson]

Post by Kevin J. McCarthy

My composition mode always opens the composition in a new tmux session (or
screen

Thank you for the detailed write up. I always enjoy reading these kinds
of posts: nuggets of wisdom from long-time users.

mutt -e 'set editor=vim-flowed' -e 'unset signature' -H "$filename"

Instead of "-e 'unset signature'", you may want to try "-e 'set
resume_draft_files'" which turns off even more undesired processing,
like user-defined headers.

Thank you, I've applied this suggestion.

I've also updated muttedit to support 3 modes:

inline: just run the session directly
window: attach to the session in a separate window
pane: attach to the session in a separate tmux pane

and improved the usage message.

The default mode is window mode if $MUTTEDIT_WINDOWPROG is set,
otherwise pane mode (-T) if $TMUX is set, otherwise inline.

And I've hacked my environment to always start mutt itself in a tmux
session, so I'm defaulting to "pane" mode personally.

The environment variable $MUTTEDIT_EDITOR can specify the editor invoked
by the submutt, default is still my "vim-flowed" command which invokes
vim with format=flowed support.

The script requires the additional scripts:

vim-flowed if not overridden, for the editing

rmafter, for the temp file cleanup

shqstr (or shqstr-sh), for command line string escaping

all available from the same place as muttedit:

https://bitbucket.org/cameron_simpson/css/src/tip/bin/muttedit

Cheers,
Cameron Simpson <***@cskk.id.au>

[Kevin J. McCarthy]

Post by Cameron Simpson

Post by Kevin J. McCarthy

My composition mode always opens the composition in a new tmux session (or
screen

Thank you for the detailed write up. I always enjoy reading these kinds
of posts: nuggets of wisdom from long-time users.

mutt -e 'set editor=vim-flowed' -e 'unset signature' -H "$filename"

Instead of "-e 'unset signature'", you may want to try "-e 'set
resume_draft_files'" which turns off even more undesired processing,
like user-defined headers.

Thank you, I've applied this suggestion.

Hmm... it looks like $text_flowed was somehow turned off. I hope this
wasn't due to my suggestion. :-/

Setting $resume_draft_files treats the -H filename just like resuming a
postponed draft. This means send-hook's are not evaluated. If you rely
on that to turn on $text_flowed, you may want to add that to the command
line, or perhaps go back to just 'unset signature'.

[Kevin J. McCarthy]

Post by Kevin J. McCarthy
Setting $resume_draft_files treats the -H filename just like resuming a
postponed draft. This means send-hook's are not evaluated. If you rely
on that to turn on $text_flowed, you may want to add that to the command
line, or perhaps go back to just 'unset signature'.

Or move the setting to a send2-hook instead, which is evaluated for
resumed files.