Re: Preferred way to get imap emails

[Erik Christiansen]

On 28.07.19 12:21, Cameron Simpson wrote:
> On 27Jul2019 22:40, Pankaj Jangid  wrote:
> > On Sat, Jul 27, 2019 at 11:41:52AM -0400, Patrick Shanahan wrote:
> > > I still use fetchmail and with imap accounts including google.  and
> > > have no problem.
> > > 
> > Probably I'll try it again. This was my favourite tool. But then I check
> > that there is no change in the repository since very long. I was worried
> > if this is still maintained or not.
> 
> Maybe it is stable :-)

Indeed, with all of us using it happy and content.

My use of fetchmail and procmail differs from Matthias' only in the
omission of spamassassin, and having procmail deliver to about ten
inboxes, one for each list, one for family, and the default. Mutt then
presents them in the priority order I have selected, so that I first see what
I need to see, without having to wade through two thousand mails in one
nightmare jungle after a fortnight out on the farm. (I am at a loss to
comprehend how it is possible to deal with one chaotic dump, especially
without having a heart attack or failing to respond to important mail,
lost in the flood.)

Instead of spamassassin, I've made do with a bunch of procmail recipes,
which only let about one spam per week through. Another recipe weeds a
high traffic list, dumping stuff that won't interest me.

Erik

Re: Mbox locking, how to do it in a way that will work with mutt?

[Erik Christiansen]

On 28.06.19 21:22, Ian Zimmerman wrote:
> I happen to know that procmail tries to lock the file in _all_ the ways
> available on the system, for instance on Linux with a dotlock temporary
> file, with flock, and with fcntl.  This is a bit overkill but it means
> procmail is safe to use as long as the other program accessing the
> mailbox uses any locking at all.

And nine years ago, on 09.08.10 15:37, Michael Elkins wrote:
> On Mon, Aug 09, 2010 at 11:26:07PM +0100, Chris G wrote:
> >   +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK
> > 
> > but does that mean that to co-operate with mutt another process *has*
> > to use dotlock and fcntl?  ... and, if so, what order should one do
> > things in?
> 
> dotlock first, then fcntl.  realize that these are just advisory locks,
> which means other processes might not obey them.  mutt is conservative and
> uses multiple methods since there is no standard.
> 
> me

So, looking from the other side also, it appears that both are respected.

Erik

Making attachments [Was: Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 16.06.19 09:48, Cameron Simpson wrote:
> I compose with edit_headers=yes, so recipients and subject are part of the
> temporary file.
> 
> Also, I attach using the Attach: pseudo header, so the attachment filename
> is also part of the temp file. Provided I haven't exited the compose mode
> (when the Attach: headers turn into actual mutt attachments) I don't lose
> that state either. (I've also got fcc_attach=yes, might be handy too.)
> 
> And to ease using the Attach: header I have this vi macro:
> 
>  map ^A 1G}-:.r!exec /dev/tty; readline -B 'Attach: '^MIAttach: ^[
> 
> Those are literal ctrl-A, ctrl-M, ctrl-[ (escape) in the macro. This means
> that I just type ctrl-A to commence an attachment and I get a file competion
> capable prompt to fill out the filename.

That looks quite useful. There's also the CheckAttach vim plugin, by
Christian Brabandt. It detects words such as "attached" in the
email body, then prompts on exit to mutt, repeating until no further
attachment paths are provided - thereby doing the remembering too. It
doesn't trigger on quoted text. The set of trigger words is
configurable. It also uses an "Attach:" header.

You'd think that someone who rereads before sending wouldn't forget that
an attachment was intended, but I have found its memory useful on more
than one occasion, especially on longish emails.

Erik

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 11.06.19 12:36, Derek Martin wrote:
> I hesitate to go far as to say that if you think saving the message
> first is the right behavior, you are simply wrong... but I'm
> definitely thinking it. =8^)

I like your style, Derek. And respect that your use case works for you.
What surprises me is the surplus of certitude which refuses to countenance
a legitimate use case at variance with yours.

If a new feature had been requested, then a higher bar to adding a
config option would have more merit. But where previously supported
behaviour had been removed, then it is only fair to other users for the
replacement behaviour to be optional only. Making the new behaviour the
default is in fact an (entirely acceptable) indulgence, I submit.

Erik

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 11.06.19 13:45, Kevin J. McCarthy wrote:
> On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:
> > Something like $fcc_order or $fcc_before_send is possible,
> 
> I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds
> $fcc_before_send, default unset.

Many grateful thanks, Kevin. That leaves Derek unimpacted, while
restoration of what we had protects older use cases. Nicolas' case of a
recipient having a copy of an email, but the sender not, can be a
serious problem. For the last half year I have been exchanging
(approval) stamped plans with authorities, consultants, engineers, and
now building contractors. As I've made design changes along the way, it
is very import to know which version of the plans has been received by
which recipient - and that a quote received here applies to a specific
plans version.

> The caveats to enabling are as mentioned: message manipulation is turned
> off, so $fcc_clear and $fcc_attach are ignored.  Another change (from before
> 1.12.0) is if the Fcc fails, you are prompted to retry or save to another
> mailbox, rather than returned to the compose menu.

The caveats are just fine in my use case. I had to look up $fcc_clear,
as I've never figured out any use for message signing. (The framing
carpenters would doubtless look at me oddly if I sent such stuff.)
And, oh goody!, $fcc_attach defaults to yes, so the plans and other attachments
will be saved.

Prompting for an Fcc retry seems ideal to me. To regain that, in place of
being dumped elsewhere, is another improvement. Mission accomplished -
Mutt much improved.

> The branch is off of stable, and is fairly minimal.  I planned on releasing
> 1.12.1 this weekend with some important fixes.  If those opposed to the new
> Fcc behavior think this is an acceptable alternative, I'll be glad to
> include it in that release.

That would be brilliant, Kevin. I'll look for it next week, then.
Many thanks, again, for the effort you're putting in to make mutt the
ideal MUA - despite a variety of use cases in the wild.

Erik

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 10.06.19 11:20, Nicolas Rachinsky wrote:
> * "Kevin J. McCarthy"  [2019-06-04 09:44 -0700]:
> > On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:
> > > Does anybody know the reason of this change?
> > 
> > The most recent discussion on mutt-dev was
> > .  The issue is
> > contentious, and there are arguments on both sides.
> 
> Thank you for the reference.
> 
> > In this case, the comments by active developers seemed to be in consensus
> > that prompting if Fcc fails afterwards is a reasonable compromise.
> 
> Ok, so I will replace $sendmail by something that saves the mail
> first, since not having a local copy of a sent mail (for an easily
> avoidable reason) is just not acceptable here. :(

In the event that send fails, the local copy is essential for a resend
attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any
scenario in which mutt should risk inability to write that Fcc, through a
hang-up or conniption during sending.

We have backups for our files for a reason - recovery is impossible
without them. To deliberately create a potentially irrecoverable
situation in mutt is incomprehensible. If developers insist on the
backwards method for themselves, then is an fcc_order config option
possible for the benefit of users seeking the old reliability?

Mind you, I can avoid the problem by remaining on my old mutt, and never
updating.

Erik

Re: Compiling a newer version than the latest .deb package

[Erik Christiansen]

On 06.06.19 18:59, Cameron Simpson wrote:
> But nullmailer really sounds very promising - it has a queue and delivers to
> a smarthost, which is all most people really need on their personal
> machines.

That's about the size of it. But if a traditional mail set-up is valued,
it's only one config command for postfix:

# postconf -ev relayhost=[yourmailhost.your.isp.domain]

The [] are needed.

Update running instance:

# postfix reload

Erik

-- 
Habit is habit, and not to be flung out of the window by any man, but
coaxed down-stairs a step at a time.
  - Mark Twain, "Pudd'nhead Wilson's Calendar

Re: Compiling a newer version than the latest .deb package

[Erik Christiansen]

On 06.06.19 20:47, Frank Watt wrote:
> I thought fetchmail had nothing to do with sendmail, but that evidently
> isn't the case.  I installed nullmailer and fetchmail ceased to work.

» DESCRIPTION
 fetchmail  is  a  mail-retrieval  and  forwarding  utility;  it fetches
 mail from remote mailservers and forwards it to your local (client)
 machine's  delivery  system. «

» As each message is retrieved, fetchmail normally delivers it via SMTP
to port 25 on the machine it is running on (localhost), just as though
it were being passed in over a normal TCP/IP link. «

Here, that was sendmail 15 years ago, now postfix. AIUI, mutt can fetch
mail itself, but then where would the procmail filter go? And what would
you do for outgoing mail? (Maybe mutt can go direct in that direction too
- I haven't looked.)

> Does procmail use sendmail?

It's the other way round, going by invocation.

» procmail - autonomous mail processor
Procmail  can  also  be  used as a general purpose mail filter, i.e.,
provisions have been made to enable procmail to be invoked in a special
sendmail rule. «

For the postfix equivalent, I have run this configuration command:

# postconf -ev mailbox_command='/usr/bin/procmail -t -a $EXTENSION'

Hmmm, did I substitute $EXTENSION at that time? Let's look:

$ /usr/sbin/postconf -n | grep mailbox_command
mailbox_command = /usr/bin/procmail -t -a $EXTENSION

Nope, works as is.

So the mail path is: fetchmail -> postfix/sendmail -> procmail -> mailbox
  later: mutt <- mailbox

For a single user, that is perhaps overweight, but if that's what one is
used to setting up, then it's no bother.

Erik

Re: Compiling a newer version than the latest .deb package

[Erik Christiansen]

On 05.06.19 21:30, Frank Watt wrote:
> I wasn't clear.  I'm quite content with an old mutt, but I've come to
> the end of the line with sendmail (which I can't get to work, though
> it used to work).

I'm impressed. When I finally switched to postfix around 15 years ago, I
thought I might be one of the last sendmail users. (The vulnerabilities
reported back then were sufficient motive, despite many years of happy
sendmail use.) Postfix has a sendmail compatibility interface, and so I
administer it rather like sendmail, after set-up with postfix config. It
was pretty easy to get going. OK, like a number of others on the list, I
find fetchmail fine for pulling mail in from the ISP, and procmail for
collating it in a number of delivery mailboxes.

Can't advise on the other stuff, though.

Erik
(Who is also too content with an old mutt version to stop and update.)

Re: Saving sent e-mails in INBOX for better threading?

[Erik Christiansen]

On 30.03.19 09:37, Cameron Simpson wrote:
> Aside: I sort new-to-top, the reverse of the default, because I like to see
> the whole thread before replying. I found sorting conventionally got me
> involved before I'd seen followon posts saying the same stuff I was saying.

Hmmm ... that bears consideration. It definitely has its benefits.

...
> I use notmuch to search email; I have a couple of handle shell scripts 9with
> short names) to do lookups. Saving deciding _where_ to look - notmuch looks
> everywhere and one just has to type an ok search. Then it opens the results
> in mutt anyway for easy persual (the (l)imit keystroke is a grwat boon
> here).

Yes, something beyond mutt's search, and egrep, would be needed on one
mammoth inbox. With archived mail in over a thousand mailboxes, those
simple tools suffice amply, though. (Yeah, probably have to be slightly
OCD to put in the effort of considered archiving, but search keys can be
much looser.)

> My "inbox" is supposed to be my "priority" categories: personal email,
> family, banking. And unfortunately, nearly a bazillion other special
> criteria. Still, lists email goes to its own folder.

In contrast, priority is lost with the OP's one inbox. Pearls, spam, and
general effluvia appear in reverse date order. When I return from a week
on the farm, an important (legal) email could be at the tail end of over
1200 fresh mails. Even from one day to the next, it could be anywhere
amongst over 200.

With procmail hiving bulk traffic off to mailing list mailboxes, mutt
presents the mailboxes in my chosen priority order: residue after
filtering first. (They're unknowns, e.g. bank notices, council rates
notices, ISP invoices, bills.); then family; finally the ML inboxes in
order of interest. If time is short, the tail end misses out, but I
don't miss anything important. And I don't have to fiddle any mutt
display filters to twiddle that effect.

If higher priority mail comes in while I'm burrowing in a ML inbox, then
the next 'c' Change-Folder invocation in mutt takes me to that, for
immediate attention. It works like a bought one. :-)

Erik

Re: Saving sent e-mails in INBOX for better threading?

[Erik Christiansen]

On 29.03.19 13:37, Max Görner wrote:
> Dear list users,
> 
> thank you everyone for the valuable replies. I am a bit relieved to learn that
> others follow similar approaches. I will try to Bcc all e-mails to myself.
> That sounds a bit less hacky than saving sent e-mails in the Inbox.

Errr ... doesn't Bcc-ing yourself result in saving sent e-mails in the
Inbox? And wasn't the original aim to thread both sides of an exchange
in the one mailbox, for threading?

And isn't long-term usability severely constrained by saving a chaotic
panoply of disparate traffic in one increasingly entropic morass?
(Apologies for the rhetorical query. It is intended to evoke
deliberation.)

Erik

Re: Saving sent e-mails in INBOX for better threading?

[Erik Christiansen]

On 28.03.19 13:24, Max Görner wrote:
> Hello,
> 
> I am a very pleased Mutt user for several years now. However, I would love to
> have a threading similar to GMail, showing send and received messages in the
> same thread.
> 
> I wonder whether one could just configure mutt such as to save all send
> messages to Inbox again. Of course, that would clutter the inbox severely, but
> 
>  a) I have a hook limiting the view to ~(~N|~F) already
>  b) the cluttering might be counteracted by Mutt's threading capabilities.

Display filtering of one enormous clutter had never occurred to me as a
viable option. There are various incoming mail filtering tools in any
linux distro repository - the one I've used for decades is procmail.
I've set it to stream incoming mail to a separate inbox for each mailing
list, one for family, and the rest remain in /var/spool/mail/erik.

On list mailboxes, record is just set to "sent", as the list server
provides a copy of my mail for threading. A couple of hooks, folder and
recipient, record to =family when required. So, yes, posts & replies
thread nicely.

To further reduce clutter, and highly optimise searches, I delete 95 -
99% of all list mail, and archive any pearls in topic-specific secondary
mailboxes; there are 70 for mutt, 456 for LinuxCNC, and 1259 mailboxes
in all. (When looking for a hint on vim scripting a few minutes ago, for
a reply on another list, I only had to consider the subject lines of 205
posts in the mailbox vim_script, rather than who knows how many in the
104 vim mailboxes, let alone the umpty thousands if there were only one
inbox. (I'm still amazed at the thought.)

Mutt's mailbox name completion is one aid to navigation to one of 456
mailboxes - type a couple of charcters, tab twice, and page/scroll down the
list then presented. I also have:

$ which mls
mls is a function
mls () 
{ 
ls -xF ~/mail/*$1*
}

which gives me a shortlist from the 1259, given a few topic-related
characters.

Erik

Re: Alias completion question

[Erik Christiansen]

On 11.03.19 20:32, Jason wrote:
> To prevent this, I usually press Tab one extra time to see how many 
> matches pop up; just wondering if that's what everyone else does too or 
> if there's something that would negate the need for the extra Tab press.

That's how mailbox name completion works too. It's what I expect and use.

In comparison, bash takes two additional tabs and a 'y' to bring up a
long list after one tab has partially completed "mail/cnc":

$ ls mail/cnc_linux_
Display all 456 possibilities? (y or n)

Erik

Re: Hide a message?

[Erik Christiansen]

On 15.12.18 19:35, Cameron Simpson wrote:
> On 15Dec2018 17:01, Erik Christiansen  wrote:
> > Is it in reality even remotely "likely" that any LDA contains code to
> > search out those headers and delete them in transit? (Please feel free
> > to post any code snippets found.)
> > 
> > The assertion also seems to ignore that mutt inserts those headers
> > _after_ the LDA has delivered the messages, so there is normally no
> > possible opportunity for the claimed LDA header removal - is there?
> 
> If you use a tool which isn't mutt, yes there's some scope to lose this
> information. 

Yup, I could write an MUA, then there'd be scope for a bug, I bet. The
problem with that is that the post to which I replied posited that local
delivery agents could interfere with mutt's use of headers for internal
purposes. That's an entirely different discussion.

...

> If you use mutt to do the conversion, I'd expect flags to survive. I would
> not normally have any specific confidence that another tool would do so.

Yup, mutt's good stuff. But the post which I queried posited that LDAs
could magically mangle headers which mutt does not insert until _after_
delivery. It is not least the time-travel component which my post
queried. I do not think that you have addressed that with this new
topic of MUA comparison.

Erik

Re: Hide a message?

[Erik Christiansen]

On 13.12.18 13:05, Kurt Hackenberg wrote:
> 
> You may want to preserve message attributes -- things like, this message has
> been read, this message has been replied to, this message has been flagged,
> this message has been assigned the keyword "blorgh". Mail delivery agents,
> including procmail, are likely to drop that information.

Hmmm ... can any of that actually be true? Let's check. Mutt makes flag
and read status persistent through added headers such as:

Status: RO
X-Status: F

Is it in reality even remotely "likely" that any LDA contains code to
search out those headers and delete them in transit? (Please feel free
to post any code snippets found.)

The assertion also seems to ignore that mutt inserts those headers
_after_ the LDA has delivered the messages, so there is normally no
possible opportunity for the claimed LDA header removal - is there?

As for "blorgh", if you refer to e.g. colour keywords, then mutt assigns
colours on regexes evaluated at the time of display. There is no
connection between that and any LDA run some time beforehand.

So, is there anything factual in the assertion?

Erik

Re: Hide a message?

[Erik Christiansen]

On 13.12.18 22:05, Patrick Shanahan wrote:
> mbox still serves my needs and has never failed me.  why would I want to
> invest time and effort to change to something (anything) else?  maildir
> does not "work better" as I can see.

+1

I've used mbox exclusively since the days of SunOS4.1.3 or a bit before,
with a variety of MUAs - between three and four decades of trouble-free
use. Migrating my 1254 mboxes to mdir would not give me anything
other than an extra pile of directories and a horrifying number of
files. (What it might give the reader is his concern entirely.)

Erik

Re: [Mutt] Re: Group reply To-vs-Cc recipients

[Erik Christiansen]

On 11.12.18 17:52, Derek Martin wrote:
> On Tue, Dec 11, 2018 at 10:37:02PM +, Nuno Silva wrote:
> > > Yes, I did not think I needed to say this explicity, but it also
> > > explains why:  Because that usage is the one that corresponds to the
> > > stated purpose of those fields.  As such it is the obvious, and should
> > > be preferred, way to use them on replies.  Using the fields the way
> > > they are intended to be used, to me, adheres to the principle of least
> > > surprise.
> > 
> > Can't what is the least surprising to you be more surprising to somebody
> > else?
> 
> In general?  Of course.  But not in this particular context, no.  The
> RFC is the spec, and being logically consistent with the spec is the
> only "least surprising" that matters.

May I humbly suggest that what matters most is what Kevin thinks, as
he's the one with his sleeves rolled up. Then the thoughts of the
majority of the community bear consideration, especially when based on
reason. Last and least come a sole opinion based on taking an RFC as
evidence, then rewriting it when it fails to support an entrenched
inflexible view.

But full points for doggedness. ;-)

Erik

Re: [Mutt] Re: Group reply To-vs-Cc recipients

[Erik Christiansen]

On 10.12.18 17:29, Derek Martin wrote:
> On Wed, Dec 05, 2018 at 05:31:28PM +1100, Erik Christiansen wrote:
> > Thread comment: It's OK to be unaware of the usefulness of RFC features,
> > but it does seem odd to pretend that they're not useful just because
> > it's only others who need them.
> 
> I'm not entirely sure what you mean by this, but for the sake of
> clarity about RFC features, here's what RFC 2822 says on the matter
> (3.6.3, paragraph 6):
> 
>When a message is a reply to another message, the mailboxes of the
>authors of the original message (the mailboxes in the "From:"
>field) or mailboxes specified in the "Reply-To:" field (if it
>exists) MAY appear in the "To:" field of the reply since these
>would normally be the primary recipients of the reply.  If a reply
>is sent to a message that has destination fields, it is often
>desirable to send a copy of the reply to all of the recipients of
>the message, in addition to the author.  When such a reply is
>formed, addresses in the "To:" and "Cc:" fields of the original
>message MAY appear in the "Cc:" field of the reply, since these are
>normally secondary recipients of the reply.
> 
> It recomments Mutt's current behavior, for precisely the reasons I
> gave in support of it.  The person who opened the ticket stated that
> the expected behavior is for the recipients in the To: field to be
> preserved, but the RFC clearly states otherwise.

It clearly states that it "MAY" be otherwise. There will doubtless be
use cases where that is fully acceptable, and cases where it can be
tolerated. It does, though, seem a pity to arbitrarily munge the user's
recipient preferences, rather than preserve them. It does seem to
violate POLA.

Erik

Re: [Mutt] Re: Group reply To-vs-Cc recipients

[Erik Christiansen]

On 05.12.18 00:44, Mihai Lazarescu wrote:
> On Thu, Nov 29, 2018 at 04:12:08PM -0800, Kevin J. McCarthy wrote:
> 
> > On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote:
> > 
> > > I am curious to know in what context "someone" felt it would
> > > make a difference.
> > 
> > The ticket number is 98, but I thought mutt-users would be a better
> > place to have a discussion.
> > 
> > I can't speak for the reporter, but my understanding was the desire
> > to preserve the distinction between primary recipients, towards whom
> > the conversation is directly relevant, and others who may be just
> > being kept in the loop.
> 
> That's the meaning of To:/Cc: fields according to RFC5322
> https://tools.ietf.org/html/rfc5322#section-3.6.3
> 
>«The "To:" field contains the address(es) of the primaryrecipient(s)
> of the message.»
> 
>«The "Cc:" field (where the "Cc" means "Carbon Copy" inthe sense of
> making a copy on a typewriter using carbonpaper) contains the addresses
> of others who are to receivethe message, though the content of the
> message may not bedirected at them.»

Yes, the separate fields replicate paper based systems with a long history
of established use. Any lack of awareness of the clear distinction
between the fields merely reveals a lack of experience of situations in
which it is important, such as in many a corporate culture. Where the
recipients are all in-house but from differing departments or teams,
then leaders will be in the To: list, and significant lieutenants (and
departments passively involved) in the Cc: list. The latter to review
the content, but reply may need to be from a leader to be acceptable.
I have been involved in cross-corporate exchanges (in between physical
meetings) where corporate relationships, contractual implications, and
domain of responsibility are important considerations. And being on the
Cc: list implied a responsibility to read and consult - not reply
unilaterally.

Thread comment: It's OK to be unaware of the usefulness of RFC features,
but it does seem odd to pretend that they're not useful just because
it's only others who need them.

Erik

Re: Group reply To-vs-Cc recipients

[Erik Christiansen]

On 30.11.18 01:34, Francesco Ariis wrote:
> On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote:
> > I am curious to know in what context "someone" felt it would make a
> > difference.
> 
> I suspect work related setting. Cc: is indeed "being kept in the loop"
> while To: is "addressed specifically".
> 
> I have never noticed mutt behaviour, but the above seems a sensible
> behaviour.

+1

Spontaneous increase of entropy isn't usually user-friendly. If I hadn't
retired ten years ago, it'd make more of a difference here, but letting
the CC list know they can leave the message on the back burner is
fractionally as important as signalling the TO recipients that they
can't.

Erik

Re: smart saving

[Erik Christiansen]

On 01.11.18 19:06, Ben Fitzgerald wrote:
> When I hit "s" it would be lovely to have the last folder I saved a message
> with the same "meta" (simple case - same "from:").

That is the mutt default, in my experience. Since that is never useful
here, I set save-hooks to meet local needs. While most of mine set a
second archive mailbox for each delivery mailbox, there is one which
parallels your use-case:

fcc-save-hook '%L fam_grp' family

That sets "family" as the default save destination for anything from
anyone I've listed in a "alias -group fam_grp rita   r...@example.com"
line. It's an fcc-save-hook rather than just a save-hook to put my
replies there as well. Now _that_ is smart, and seems far more useful
than spraying emails disc-wide based on nothing more than "From:".

Erik

Re: Composing blocks checking for new

[Erik Christiansen]

On 29.10.18 12:56, Bastian wrote:
> 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

Re: Stop myself from sending an email with a particular string

[Erik Christiansen]

On 15.09.18 05:30, Francesco Ariis wrote:
> Hello Xu,
> 
> On Fri, Sep 14, 2018 at 11:18:09PM -0400, Xu Wang wrote:
> > Long story short:
> > How can I have mutt refuse to send an email if the contents contain a
> > certain string, such as the example "Erica"?
> 
> There is a script that implements a similar functionality
> 
> https://gitlab.com/muttmua/mutt/wikis/ConfigTricks/CheckAttach

If you compose emails in Vim, then simpler yet, Christian Brabandt's
long established¹ CheckAttach plugin checks for default keywords, and
the user can configure new ones in the g:attach_check_keywords variable.
OK, it will then prompt for attachments on an exit attempt, but _also_
highlight the triggering keywords - in this case "Erica". The attachment
process, spurious for this use-case, is aborted by hitting , so
the plugin adaptation is a quick and simple way to achieve the desired
watchdog function.

> The trick is simple: substitute $sendmail with a custom one.

Sounds more complex than a simple plugin install plus a Vim variable
setting, especially given the X dependencies and consequential
workarounds for terminal. 

Erik

¹ Having used it for well over half a decade, I find it invaluable.

Re: Long subject lines

[Erik Christiansen]

On 19.08.18 03:17, David Woodfall wrote:
> I sent a message with a rather long subject line earlier and it was
> split into two lines.

OK, I'm a laggard, still on mutt 1.8.0, but when I compose a three-line
subject in vim¹, separated by newlines, it is visually _joined_ into a
single line on return to mutt. Sending it to myself, it is displayed as
three lines in mutt, but more compact than composed. That may just be
wrapping of the single line.

The only other MUA I have any familiarity with is ancient "mail", and it
shows the same for the received message.

> Is there a way to avoid that? I tried setting tw=0 in an autocmd in
> vim but it still got cut. I checked that tw was still set to 0, so I
> assume that mutt cuts it before vim opens it.

Seeing three lines in vim being joined to one in mutt, I don't expect
vim settings to have much effect in the MUA.

> Or is this a limitation of the RFC that subject lines need to be
> under a certain length?

My simple experiments suggest that it's just mutt joining vim's multiple
lines into one, then wrapping that for useful display on receipt.

Erik

¹ edit_headers is set.

Re: no "on behalf of" me in my reply to mailing list

[Erik Christiansen]

On 24.07.18 15:32, Hang Yuan wrote:
> So sounds it's my email client's problem which can't show email header
> correctly? I can see you email address but can't see my address
> displayed in my reply. Instead, mutt-users-boun...@mutt.org is showed.

Your post shows here as:

>From mutt-users-boun...@mutt.org  Tue Jul 24 17:42:50 2018
From: Hang Yuan 

My header weeding settings are:

ignore *
unignore  In-reply-to References Reply-To cc To From Organization Date Subject
hdr_order In-reply-to References Reply-To cc To From Organization Date Subject

I.e. Remove all headers, then add back those desired. It is enough to
give me both From headers.

Is it possible that your problem lies in that area?

Erik

Re: Disable reply quote

[Erik Christiansen]

On 11.07.18 10:29, Stefan Hagen wrote:
> When mails come to my support level, they often contain 30+ outlook 
> style replies ->multiple pages of mail history. When I reply to these
> emails, Mutt quotes the full history.
> 
> I always manually delete the quote marks down to the end of the email,
> then copy relevant parts to the top and quote it. (leaving the history
> untouched)
> 
> Having mutt not quote the reply automatically saves me one step.

In the absence of a method in mutt, I'd use a vim autocommand, triggered
by the mutt-specific name of the temporary file. If you use another
editor, then it can probably do something similar. The one in my .vimrc:

au BufNewFile,BufRead   ~/Desktop/mutt-*   call Set_for_mutt()

doesn't perform any auto-edits, but you could put anything desired in
the editor function called, and it'll only run when the editor is
invoked by mutt.

An alternative might be to invoke the auto-edit via command-line
arguments added to the "set editor=myeditor" line in .muttrc. (Not
tried)

Erik

Re: Problem with strict_threads

[Erik Christiansen]

On 05.07.18 13:39, David Woodfall wrote:
> I've noticed now that my replies in that thread don't have a
> In-Reply-To for some reason. When I tag one and attach it with & as
> you said it joins fine and adds that.
> 
> Why wouldn't mutt add that? It works fine eg in lists.

It's ticked over 23:00 here, and I'm not recalling anything on the
missing In-Reply-To headers, but if there's still poor threading after
that's fixed, then here's what my notes say I did, back when:

Debug: Maillist posts, lacking In-Reply-To or References headers, and with
   "Fwd: Re: Fwd: Re:" pollution in the Subject, started multiple
   threads, and mutt didn't cope:
Diagn: :set ? strict_threads  
   strict_threads is unset
   :set ? sort_re
   sort_re is set
   # Default reply_regexp is simplistic, though.
Fix:   Added in .muttrc:
   # Note:  Keep reply_regexp lower-case, to keep it case-insensitive.
   #
   set reply_regexp="^(((re(\\[[0-9]\\])?|aw|fw|fwd|\\?\\?|):)[ \t]*)+"

There are even fancier regexes in the list archive, back in 2009/2010,
but they have more ambitious agendas.

Erik

Re: Problem with strict_threads

[Erik Christiansen]

On 05.07.18 12:53, David Woodfall wrote:
> I've just set up things so that record=^ which works fine, and I
> copied a bunch of old sent messages to a folder to see the whole
> thread.  However I see the thread order is broken.

OK, we have "set sort=threads", as the above implies some threads
showing.

> I tried setting strict_threads but it doesn't help.

That just reduces threading, by disabling pseudo-threading.
Having $strict_threads and $sort_re unset should compensate for missing
threading headers, perhaps too much, if a subject recurs in later
threads.

> EG I have a thread with a friend (he uses the email app in Win10 and
> the messages have outlook.com IDs) and checked all his Message-ID and
> all my In-Reply-To and they look like they should match properly.
> Each message contains the correct ID and Reference AFAICS.
> 
> Any ideas what to try to solve this?

What happens to the headers when you use & to join a tagged mail to a
thread? Presumably the thread display is now OK, and the change in the
headers will show whether it's In-Reply-To or a Reference that was
missing. (Whenever I've done that, mutt has added an In-Reply-To, IIRC.)

Erik

Re: Bottom posting v top posting

[Erik Christiansen]

On 13.05.18 15:31, Brian Salter-Duke wrote:
> On Sun, May 13, 2018 at 03:03:55PM +1000, Erik Christiansen wrote:
> > On 13.05.18 09:52, Brian Salter-Duke wrote:
> > > It is time we gave up bottom posting!
...
> Eric, I tried to email you direct, but you do not allow that, so I will have 
> to
> send to the list my anger at your post.

Please understand that I would have returned it to the list in any event.

> Who the hell do you think you are to lecture me in that way?

Anger is good in a dangerous situation, but here it does seem to impede
understanding. From your fulsome fullquote, I have requoted only the
dictatorial challenge in your OP, which caused me to offer up a pin to
the balloon of your fantasy.

> I have been using mutt for pretty well as long as you have no doubt. I
> am perfectly happy to bottom post. I have always bottom posted on the
> mutt lists. I understand why the mutt community prefers it. I prefer it.

No, you have told us we must abandon our optimal practice in favour of
an ignorant fashion. I responded accordingly, in a constructively
educational manner, appropriate to the nature of the challenge.

> The problem is that nobody outside the mutt community who email me use it.

A calmer reading of my post ought to reveal that it is an attempt to
help you learn that a difference is not 'a priori' a problem. I write
Danish to my relatives, German to some friends, and English where that
suits. It is no mark of a developed intellect to be so dogmatic as to
insist that various communities must conform to a single norm. If you
think carefully, you will observe that in the sentence above, you
logically connect the problem with the last pronoun there. That is where
you will find the remedy, rather than in attempting to force conformity
on disparate communities.

> Also, it would not go down well if I tried to educate my research colleagues 
> at universities all over the world to bottom post.

On this list we would ask them to do so. As for elsewhere, I refer you
to your sig.

> We have had 20 years or so to educate people to bottom post. We have almost
> entirely failed.

No we have made no attempt to do so outside lists, but you still fail to
learn to tolerate difference in other communities.

> It turns out that my random sig that I use for this list is highly 
> appropriate.
> I assure you that it really is random.

Yes it is ironically appropriate. If only you could learn from it what
you have so far failed to learn from gentle prodding of your intellect,
then we would be spared further effort to help you man up and accept
evident difference.

Erik

-- 
Gnothi seauton, the Ancient Greek aphorism "Know thyself", was inscribed in the 
pronaos (forecourt) of the Temple of Apollo at Delphi according to the Greek
periegetic (travelogue) writer Pausanias. The Suda, a tenth century encyclopedia
of Greek Knowledge, says it is a warning to pay no attention to the opinion of
the multitude.

Re: Bottom posting v top posting

[Erik Christiansen]

On 13.05.18 09:52, Brian Salter-Duke wrote:
> My partner reads gmail on her phone or tablet. She reads my messages but does
> not realise that if she scrolls down she can see her message that I replying
> to. If I had bottom posting, she would never have read my message, thinking
> that some how she had got her email back again. The use of phones for email
> alters the game. It is time we gave up bottom posting!

The world has an infinite supply of fools who stumble through it,
unaware that it is the adaptor who survives. NO, it is not the list
community which needs to adapt to one intruder, but the converse.

Bottom post, and we will read. Only then can you hope for a reply.
Understand that we have t-prot for TOFU protection, and do not need to
scroll down as long quotes are compressed. Trim your quotes, not out of
consideration for the reader if you lack that, but in order for your
reply to be seen and read.

Try to learn. It is a prerequisite to becoming adaptable. The first
survival tactic is when in Rome, do as they do. We have no problem with
you sending inverted messages in other domains. Go your hardest, but to
attempt to impose that foolishness on our community is infantile and a
symptom of slow learning.

Thinking can be a useful path to learning. Is it possible for you to
imagine that if you could learn to trim your quotes to the essential
minimum of a line or two, then bottom posting works well on most
screens, and even on phones if you prefix the whole message with:
"For clarity I'm answering in context, see below:"

Your partner's ignorance and your failure to compensate do not compel an
entire community to pander to your slow learning. Please man up and adapt. 

Erik

Re: mailing-list to bugs

[Erik Christiansen]

On 08.05.18 20:46, Derek Martin wrote:
> I dare say no one should want to work in Perl anymore...  It's such a
> horrible mishmash of a lanugage.

+1

> But C is probably not the best tool for this job either.  Python has
> modules for handling e-mail and for talking to bugzilla, and for my
> money it's way, way nicer to code in than Perl.

A language which handles (ERE) regexes directly is distinctly to be
preferred. Labouring like a Trojan in C has whiskers on it. OK, I have
done some work with lex & bison, coupled with a regex library, and that
allows the job to be done in C, but even that intermediate level
approach is a lot of work, with resolution of parser conflicts making a
long job of what is much quicker with a less grammatically hidebound
parser in Awk or similar.

Given the expressed familiarity with C, I'd propose Awk as the parsing
language. It has POSIX EREs and a C-like syntax. The Addison-Wesley book
"The AWK Programming Language" was written by the language's authors,
and is a goldmine - brief, to the point, and wonderfully indexed. It is
admittedly too old to include more recent developments like coprocesses,
which allow an Awk daemon to talk to other processes over pipes, but you
can just invoke Awk once per email.

Erik

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

[Erik Christiansen]

On 27.04.18 08:57, Kevin J. McCarthy wrote:
> I always thought $followup_to was a pretty nice feature.  While I
> sympathize with Matthias, the mischief was the result of
> misconfiguration, and Mutt requires nothing if not attention to the
> documentation and configuration.
> 
> However, if there is a strong majority of mutt-users subscribers that
> agree with $followup_to defaulting to 'no', I'll make the change.

Here,  declares: "Mutt also supports the Mail-Followup-To header.
When you send a message to a list of recipients which includes one or
several subscribed mailing lists, and if the $followup_to option is set,
Mutt will generate a Mail-Followup-To header which contains all the
recipients to whom you send this message, but not your address."

The request for a changed default seems to have arisen from Matthias'
Mail-Followup-To header erroneously including his own address. It does
seem likely that this problem arises from misconfiguration, as no-one
shares his difficulties. Here I have both subscribed lists, and some not.
In the latter case, Mail-Followup-To is not generated, and in the former
I find only the other recipients, as described in the manual. That is
with no $followup_to setting, i.e. default, as Matthias has.

What other configuration is required in order to place the sender's
address in Mail-Followup-To, in contradiction to the manual entry is
then a curiosity.

Erik

Re: View HTML without autoview

[Erik Christiansen]

On 14.03.18 23:23, David Woodfall wrote:
> On (14/03/18 16:01), Ian Zimmerman  put forth the 
> proposition:
> > On 2018-03-14 13:13, David Woodfall wrote:
> > 
> > > > Previously, I used elinks and it works fine with autoview, however
> > > > when I try to pipe to it it also renders the headers instead of just
> > > > the body.
> > 
> > When you try a pipe, is that piping the message (as a pipe command would
> > do in the index view) or just the html MIME part (as a pipe command in
> > the attachment view would do)?
> 
> It does the whole message. I seem to get messages where the entire
> message is html with no separate html part. Mostly from ebay.co.uk,
> even though I set to receive mail in plain text only.

To strip headers there, is pipe_decode useful? The manual says: "When
set, Mutt will weed headers and will attempt to decode the messages
first." Whether an "ignore *" is also needed to make it weed out all
headers, I haven't tested.

Erik

Re: Reply with another email as attachment?

[Erik Christiansen]

On 14.03.18 10:48, Tim Chase wrote:
> On 2018-03-15 00:37, Erik Christiansen wrote:
> > Yup, forward:
> > View the email to attach.
> > Hit 'f', and mutt will prompt: Forward as attachment? ([yes]/no):
> > Hit Enter, compose the accompanying email, with forward address,
> > etc.
> 
> I just tried this (both with an individual message as well as tagging
> multiple and using ";f" to forward the tagged messages) and they
> ended up in-line by default.  It looks like you might have to fiddle
> with the mime_forward quad-option which defaults to "no", setting it
> to an "ask*" option.

Uh-oh, you're right. Dusting off my .muttrc, I see that I set
mime_forward to ask-yes.

Erik

Re: Reply with another email as attachment?

[Erik Christiansen]

On 14.03.18 12:48, David Woodfall wrote:
> I have recently been in a discussion with a tech support person about
> some emails that I have been receiving and I was asked to attach one
> of them to a test email that she sent me.
> 
> I couldn't find how to do that, apart from actually finding the file
> and attaching it that way. When I pressed 'a' to attach and then '?'
> for a list I had a list of my folders up, but mutt wouldn't let me enter
> them and gave a 'couldn't attach ' error.
> 
> Is there a way of doing this?

Yup, forward:
View the email to attach.
Hit 'f', and mutt will prompt: Forward as attachment? ([yes]/no):
Hit Enter, compose the accompanying email, with forward address, etc.

Erik

Re: line editor keybindings

[Erik Christiansen]

On 13.03.18 11:13, Marco Dickert wrote:
> On 2018-03-13 20:50:20, Erik Christiansen wrote:
> > On 13.03.18 10:09, andreas.muel...@biologie.uni-osnabrueck.de wrote:
> > >   can I switch the editor key bindings to the vi style ?
> > There is better than that - you can use vim as the mutt editor, with
> > this line in ~/.muttrc:
> > 
> > set editor=vim
> 
> You also may want to use a mutt-dedicated vim configuration, like I do:
> 
> 
> set editor="/usr/bin/vim -c ~/.mutt/vimrc"
> 

Yes, good point. It can alternatively be handled by a vim autocommand,
e.g.:

au BufNewFile,BufRead   ~/Desktop/mutt-*   call Set_for_mutt()

function! Set_for_mutt() 
setlocal textwidth=72 
setlocal formatoptions=qrjt

" Change subthread Subject:  
noremap  ^[gg/^Subject:^MWi [Was: ^OB
"
"Don't quote sig in email replies:
normal :g/^> -- $/,/^$/-1d^M/^$^M^L
endfunction

And for prompting for attachments if they're mentioned in the email,
install CheckAttach.vim & enable it by filetype:

" CheckAttach.vim is a filetype plugin.
filetype plugin on

Note: In ~/.muttrc , there's:

set tmpdir="~/Desktop"  # If not in ~/postponed after a crash, look here.

The autocommand's second field needs to match.

Separate .vimrc files slightly smaller, but raise the problem of
maintaining multiple copies, when common lines are edited. When
there's only one, the problem does not arise.

Erik

Re: line editor keybindings

[Erik Christiansen]

On 13.03.18 10:09, andreas.muel...@biologie.uni-osnabrueck.de wrote:
> 
>   can I switch the editor key bindings to the vi style ?

There is better than that - you can use vim as the mutt editor, with
this line in ~/.muttrc:

set editor=vim

On a *nix platform, it would be very poor to be unable to use your
favourite editor everywhere.

Erik

Re: Mailing list status

[Erik Christiansen]

On 13.03.18 08:31, Cameron Simpson wrote:
> On 12Mar2018 12:31, Kevin J. McCarthy  wrote:
> > The new mailing list server uses GNU mailman.  There are likely a few
> > things that need to be tweeked.  Please let me know about any issues.
> 
> I notice that the Sender: header now says {listname}-boun...@mutt.org
> whereas before it said owner-{listname}@mutt.org. (Because my mail filing
> rule no longer matched.)

Works flawlessly here, as at some point I'd switched procmail to look
at List-Post: instead. (Perhaps there was some other change some years
back, to prompt that.)

Many thanks Kevin, for keeping us afloat - and for building the ship.

Erik

Re: Remove Subject prefixing (when answering/forwarding) possible?

[Erik Christiansen]

On 28.02.18 12:10, Patrick Shanahan wrote:
> some time ago, in an earlier age, Sven Guckes posted a sed or perl filter
> to hide "Subject:" additions, but I seem to have lost it, and he seems to
> be missing too  :^(
> 

The following has served for so many years in my .procmailrc that I
can't recall if it was Sven who provided the method for _stripping_ that
cruft from the incoming subject header.

   :0
   * ^TO_luv-main@.*luv.asn.au
   {
# We need the subject line _content_, minus [list-name]:

  SUBJECT=`formail -czX "Subject:" | sed -re "s/Subject:// ; s/ 
\[luv-[a-z]*\]//g"`
   
# Header filter leaves body alone:
  :0fhw
  | formail -i "Subject: $SUBJECT"
   
# Delivery, with lockfile:
  :0:
  luv-main
   }

The second sed regex could perhaps be generalised, rather than just
retargeted for your problem list, but a quick fix is a good fix, so
long as it does the job, I figure.

Changing "-i" to -I" on line 10 stops the received subject header being
retained as "Old-Subject:", but retaining it is a reminder that the post
has been trivially munged.

The ^TO_ on line 2 accepts either "To:" or "Cc:", as adjunct to simple
duplicates management via formail. (Forces "courtesy copy" to the list
mailbox.)

Erik

Re: mutt manual: i have bad startings into learning mutt

[Erik Christiansen]

On 07.02.18 22:37, kalle wrote:
> In the manual v.1.9.2, chapter "2.1 Index" it says
> 
> "The index is the screen that you usually see first when you start Mutt. It
> gives an overview over your emails in the currently opened mailbox."
> 
> The problem is: there are no mails to see, because there is no mailbox of
> mine open and I don't know how to do this.

Then mutt is failing to find your spoolfile:

»
3.299. spoolfile

Type: path
Default: (empty)

If your spool mailbox is in a non-default place where Mutt cannot find it, you
can specify its location with this variable. Mutt will initially set this
variable to the value of the environment variable $MAIL or $MAILDIR if either
is defined.
«

If further diagnosis is needed, it might be useful to post your mutt
version number. (From mutt -v)

Although I have neither $MAIL nor $MAILDIR defined in the environment,
mutt has always found the mail spool, as is the case for most mutt users,
I expect.

In the index view, press y for the mailboxes view, which in my case
presents:

1 -rw---  1 erik erik 6.1M Feb 05 15:41 =avr_chat_u
2 -rw---  1 erik erik  12M Jan 17 13:23 =avr_gcc_u
...
16 -rw-rw  1 erik mail 9.4M Feb 08 12:05 
/var/spool/mail/erik

If your spoolfile is in some unusual place, then you now have three ways
to tell mutt where it is located.

As you are using linux on your host, try:

$ ls /var/spool/mail/

to see what is there. (And go from there.)

For later: If you use some utility to fetch and sort mail into multiple
inboxes, e.g. one per mailing list, then the "mailboxes" command can be
used in ~/.muttrc to configure those as well.

> 
> It is the third time already that I try to learn mutt but having no mails to
> start with, not knowing what is meant by a 'mailbox' and how to administrate
> it, even when reading in the newbie manual not getting to a point.

The  manual does discuss mailboxes, describing both mbox and maildir
formats. Once you've found your spoolfile, then you can inform yourself:

$ file /var/spool/mail/erik
/var/spool/mail/erik: UTF-8 Unicode text, with very long lines

$ view /var/spool/mail/erik

to see what the mbox format looks like.

Your persistence is admirable, and with the help of a few answered
questions, I'm sure you'll succeed. It'll be interesting to hear how the
spoolfile managed to hide.

Erik

Re: Searching sent folder

[Erik Christiansen]

On 07.02.18 03:54, David Woodfall wrote:
> > When I use search or limit in my sent folder on an address it shows no
> > matches. They seem to only work on subjects. Is there a way to get
> > them to work on addresses?
> > 
> > -dave
> > 
> 
> I found limit ~C


In the index, "/ ~h elephant" will find any such hiding in headers.
Haven't you used ~b to search mail bodies? Admittedly the latter does
not work on collapsed threads, in version 1.8.0.

Erik

Re: save attachment content as if they are in pager

[Erik Christiansen]

On 02.02.18 11:55, Yubin Ruan wrote:
> On Thu, Feb 01, 2018 at 07:32:29PM -0800, Barton Janes wrote:
> > The trailing = is usually caused by the text encoding of "quoted Printable"
> > 
> > https://en.wikipedia.org/wiki/Quoted-printable
> 
> Are there any ways to save the decoded message rather than the encoded one?

The Pager menu has:
s  decode-save  make decoded copy (text/plain) and delete

Have you tried it? (Pressing '?' in the menu shows the key mappings
available to you, including any mappings you've added.)

For DIY handling of quoted-printable, one could pipe to:
   $ apt-cache search qprint
   qprint - encoder and decoder for quoted-printable encoding
   qprint-doc - qprint quoted-printable encoder/decoder (documentation)

> To make it more general, is it possible to save the content generated by some
> auto_view commands, without having to split the email and type those commands
> separately in command line?

If you wanted to select a specific multipart alternative in the
Attachment Menu, then there is only 's' or '|'. With a key mapping to
invoke a macro, you could pipe the alternative to qprint, outputting to
a file - with minimal keystrokes.

Erik

Re: Quote multiple messages in new message

[Erik Christiansen]

On 17.01.18 11:43, steve wrote:
> Hi,
> 
> I would like to create a new message containing quotations of others
> messages (in order to avoid copy-pasting). I tried to tag some messages
> with T then type ;m but this create an empty new message. I've searched
> the web with many different key words but failed to find a solution.

If you follow tagging (I just use t to individually select) with ;L (if
a list is defined) or else ;r , then they'll be quoted - and the list or
the reply addresses will be in the To: header. If you have edit_headers
set, it's easy to substitute another address if you're not replying.

Erik

Re: Possible to not leave pager if up on first or down on last message?

[Erik Christiansen]

On 20.12.17 23:30, Scott Kostyshak wrote:
> > Ben Boeckel wrote:
> > bindpager   previous-line
> > bindpager next-line
...
> 
> Thank you for the replies, Todd and Ben.
> 
> It seems there's not a configuration variable for what I would like to
> achieve.

On the contrary, Ben's key bindings do keep you in the pager,
substituting line up/down for message up/down. (It's something which
I've also adopted long ago, as the default is alien.)

Erik

Re: split or merged mbox/record

[Erik Christiansen]

On 29.11.17 15:09, Daan van Rossum wrote:
> Dear mutt users, I use two separate mailboxes for received and sent
> emails, called "mbox" and "sent" respectively.  When reading old
> threads I sometimes wish I had sent and received mail in one and the
> same mbox.  I know it is easy to merge sent and mbox in mutt.  But I
> wonder what the disadvantages are.

Indeed, splitting outgoing and incoming messages prevents presentation of
the whole thread, so only has disadvantages, AFAICT.

However, throwing all email into one enormous porridge vat is also
disadvantageous, as hunting up and down for the highest priority mail to
deal with next is inefficient.

The method I've settled on is to have an inbox for each mailing list I'm
on, one for family, and the default inbox for the rest. Of the 199 mails
which arrived yesterday, only a dozen or so were unclassified, and the
rest were sorted by procmail.

Placing +/family_u /var/spool/mail/erik first on the first "mailboxes"
line in .muttrc gives them priority when changing mailbox with the 'c'
command.

An fcc-save-hook defaults email saving to "family" from "family_u",
although they could be left in situ. But mailing lists are another
matter. After deleting a large proportion of posts, I find it useful to
sort the informative posts according to subject. For the LinuxCNC list,
I have 454 subject-specific mailboxes, reducing the number of posts to
be searched on a specific topic from 22792 to just dozens or a few
hundred at most.

Erik

Re: collapsed threads that have unread/new mails inside

[Erik Christiansen]

On 17.09.17 04:19, Yubin Ruan wrote:
> Hi,
> How to identify collapsed threads that have unread/new mails inside?
> I want to assign some color to those that so that it can be distinguished, but
> currently I know no expression to express a "collapsed thread that has
> unread/new mails inside".

The 'n' immediately after the message number indicates new mail in a
collapsed thread. If colour is needed too, then a regex detecting that
will probably be required.

However, I have for a long time settled for:

set collapse_unread=no

in .muttrc, keeping such threads uncollapsed. It saves both time and
labour, since it's not necessary to manually uncollapse the thread to
see what is unread in there.

Erik

Re: Attachment saving and piping: what of the headers?

[Erik Christiansen]

On 10.07.17 14:29, Ian Zimmerman wrote:
> I tried both a straight save, and a pipe to a cat command.  In either
> case, no headers are present, and neither is the separator line; the
> file just contains the body and that's that.

Curious. Here, a "| cat > /tmp/fred" produced a copy of your post,
complete with 80 lines of headers. That's with pipe_decode unset, and
Mutt 1.8.0 (2017-02-23).

> I am confused.  Is there a way to save a MIME part in mutt that includes
> the headers?
> 
> FWIW, pipe_decode is unset.

Strange indeed. In similar circumstances, I'd do a :set nopipe_decode,
for emphasis. If a coffee and a break doesn't help with the gremlins,
then a new mutt version?

Erik

Re: Mutt - Neomutt and Debian Stretch

[Erik Christiansen]

On 30.06.17 16:25, Kevin J. McCarthy wrote:
> Starting with a vanilla mutt tarball and adding a set of patches, broken
> out by bug fix or feature, is fairly standard practice.  It's easy to
> see what is changed, and I think is still fair to call mutt.
> 
> If you take a vanilla mutt tarball and add a 30k+ line "blob patch"
> called "neomutt", I don't think it's fair to call that mutt anymore.
> 
> If you don't even package a vanilla mutt tarball, but take the tarball
> from a completely different project, it most definitely is not mutt.
> 
> I think it comes down to accountability.  If you know the changes you
> are making, then there is something of a guarantee the result is a
> *Debian* packaged version of *Mutt*.  Debian may have made some changes, but
> is vouching that this is essentially Mutt, plus changes they comprehend
> and can vouch for.
> 
> By switching out the tarball to someone something generated by another
> project, or adding a ginormous "blob patch", Mutt can not and should not
> vouch for it.  You are relying on the other project's reputation, not
> ours.  It is then completely inappropriate for you to call it mutt.
> It's not mutt.  It's not "mutt + neomutt".  It's neomutt.
> 
> > I don't believe that your work is lost, all your code ends up in
> > Debian (and derivatives) and yes there will be patches on the top of
> > it.
> 
> Perhaps lost was the wrong word.  The code may be mixed in, but as Mutt
> project maintainer, the package has nothing to do with my work anymore.
> The package you are calling "mutt" is not something I've helped create.
> Your version "1.8.3+blah" is not even remotely the code I decided should
> be in version "1.8.3".  It's code the NeoMutt project made the decision
> on.  Is it that hard to understand why calling it mutt upsets me?

Looking in /usr/local/src/mutt-1.8.0/COPYRIGHT, I see a long history of
copyright assertion:

Copyright (C) 1996-2016 Michael R. Elkins 
Copyright (C) 1996-2002 Brandon Long 
Copyright (C) 1997-2009 Thomas Roessler 
Copyright (C) 1998-2005 Werner Koch 
Copyright (C) 1999-2014 Brendan Cully 
Copyright (C) 1999-2002 Tommi Komulainen 
Copyright (C) 2000-2004 Edmund Grimley Evans 
Copyright (C) 2006-2009 Rocco Rutte 
Copyright (C) 2014-2016 Kevin J. McCarthy 

and a GPL2 assertion. IME, while that permits derivative works, it does
not permit a derivative work to purport to be the copyrighted original
work. Misrepresenting the "debneomutt" work as "mutt" would seem to
clearly contravene the asserted and enforcible licence.

We pay our FOSS benefactors only in respect and correct attribution. To
fail to do so is IP theft and or misrepresentation, I contend, and is
dishonest and intolerably reprehensible. It reflects appallingly on the
debian distribution. It needs to be rectified immediately.

Erik

Re: Change default From header when click on mailto

[Erik Christiansen]

On 13.06.17 13:18, Marcelo Laia wrote:
> I have four accounts configured in mutt. I use mutt+msmtp+offlineimap
> 
> My personal account is marcelol...@gmail.com
> 
> How ever, when I click on a mailto link (webpages), mutt was loaded with a
> different From header. It's loaded with my business address. How I change that
> behaviour?

To force the from address, you can, in .muttrc:

set from="marcelol...@gmail.com"

That relies on: set use_from=yes 
but that is the default.

(I notice that I set "from", but don't recall why I needed to.)

Erik

Re: Mutt freezes when network is off [was: sendmail in background?]

[Erik Christiansen]

On 12.06.17 02:05, Yubin Ruan wrote:
> Thanks my friend. Postfix works pretty well :-)
> 
> There is only problem I found when testing Postfix + mutt: I uses
> Postfix for smtp and mutt deals with imap for me.

That is the problem, then. Many of us use fetchmail (or similar) to
handle the imap or pop3, then procmail to sort into multiple mailboxes,
if that is also desired. Either way, there is no freezing of mutt.

fetchmail - SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
fetchmailconf - fetchmail configurator

The latter is helpful when getting started.

Note: fetchmail normally delivers via SMTP to port 25 on the machine it
is running on (localhost), or if no port 25 listener is available, but
your fetchmail configuration was told about a reliable local MDA, it
will use that MDA for local delivery instead.

> But mutt will freeze when the network is off. Therefore, you can not
> do anything at that time, let alone sending email.

That is then not a useful configuration. Taking a process half way can
end up like that.

Erik

Re: View email in external editor

[Erik Christiansen]

On 22.05.17 03:49, Yubin Ruan wrote:
> How to view email in external editor such as VIM?

Hello time-traveller,

Yes, via "set pager= ...". The manual has an example which sets it only
for one mail folder:

message-hook ~A 'set pager=builtin'
message-hook '~f freshmeat-news' 'set pager="less \"+/^  subject: .*\""'

Would you invoke "vim -R" or "view", to somewhat reduce the risk of
corrupting received mail through finger fumbles? Hey, maildir format
might have an advantage at last - the received mails could be owned by
"mail", with write permission denied, but you could own the directory,
so you can delete the files despite not owning them. There are such neat
ways to do things on *nix.

Erik

Re: Scroll-off option for mutt

[Erik Christiansen]

On 07.05.17 03:36, Yubin Ruan wrote:
> Hi,
> Is there a scroll-off option for mutt? In vim, you can use
> set scrolloff = 7
> to make the editor scroll rather than changing pages when you get to the end 
> of
> the current page, so that you can see things continuously. But for mutt's 
> pager,
> it seems not possible to do so. Anyone know any alternative methods?

AFAICT, there's only menu_scroll, and half_up/half_down (half page)
commands. If you were to bind the latter to a pair of keys, then you'd
almost half have scrolling in the pager.

On the other hand, if one were to set $pager to use vim rather than the
built-in pager, then scrolloff would be gained ... but the ability to delete
the message within the pager would be lost - you'd have to exit first.
Naturally, vim would be invoked read-only, e.g. as "view", for a modicum
of clumsiness protection.

The pager can be set in hooks, e.g. so the external pager is only used
for some folders or senders.

Erik

Re: How to tell GUI MUAs to show message in a fixed font?

[Erik Christiansen]

On 28.04.17 13:22, Greg Hurrell wrote:
> Fun fact, pretty much every message in this thread looks terrible in Google 
> Inbox on iOS (and presumably Gmail on iOS) because the lines are all 
> hard-wrapped but too long to fit on the screen, leading to alternating long 
> (soft-wrapped) and short (hard-wrapped) lines. Looks nice in mutt, of course, 
> but less than 1% of the people I exchange email with are using that, so I 
> decided to set 'textwidth' to 0 in Vim, which means my emails have long lines 
> in them (gasp!) and mutt will automatically use quoted printable to format 
> them, which looks decent pretty much everywhere:

Impressive. Works well in mutt, too. But when it comes time to reply to
such niftiness, we might be better off hard wrapping it, to restore the
plaintext quoting - at least when multiple authors are quoted, or we
won't know what was written by Arthur, Martha, or Mo.
(Maybe the GUI world doesn't fuss much with attribution?)

Erik

Rich text & Mutt [Was: How to tell GUI MUAs to show message in a fixed font?]

[Erik Christiansen]

On 28.04.17 10:44, Darac Marjal wrote:
> On Fri, Apr 28, 2017 at 07:16:19PM +1000, Erik Christiansen wrote: 
> >On 27.04.17 09:21, Darac Marjal wrote: >> On Wed, Apr 26, 2017 at 
> 08:54:45PM +, Grant Edwards wrote: >> > OK, so how does one do that 
> within mutt? >> >> I would suggest that the most prudent approach is to 
> use a lightweight >> markup language (LML). LMLs tend to be designed 
...

Darac, I'm sorry, but that run-on corruption of email quoting is quite
unreadable. A failed experiment perhaps?

Further down, the lack of leading ">>" makes some lines of my post
appear to be part of your reply - very confusing. (I have mutt display
unquoted text in green, quoted in yellow, in addition to the ">>"
quoting. Corrupt those boundaries, and it's unclear what's coming or
going.)

FWIW, I did see two red words and one underlined in the soup, so mutt
can render your rich text - just not formatted so it can be read.

Note: Vim preserves email quoting when flowing a paragraph with gq}.

Erik

Re: How to tell GUI MUAs to show message in a fixed font?

[Erik Christiansen]

On 27.04.17 09:21, Darac Marjal wrote:
> On Wed, Apr 26, 2017 at 08:54:45PM +, Grant Edwards wrote:
> > OK, so how does one do that within mutt?
> 
> I would suggest that the most prudent approach is to use a lightweight
> markup language (LML). LMLs tend to be designed such that, while they
> CAN be rendered into a presentation form, the source code is also
> (relatively) legible.
> 
> So, let's say I wanted to write something in bold.

Ahem, message composition is performed in the editor, either vim or
emacs for the majority of mutt users, I expect. And vim is
latex-friendly (Try :help latex). Then there's the vim-markdown plugin
if that's preferred.

Either way, format faffing is exclusively editor work. It has nothing
to do with the lid on the SMTP pipe - the MUA. That deals with composed
messages - it should not recompose them in transit.

> In HTML that could be bold LaTeX, it would be \textbf{bold}. But in markdown, it's simply
> **bold**.
> 
> A good LML would have a MIME type associated with it (I see that
> markdown does, but reStructuredText doesn't, for example), so it can
> either be viewed (as source) in the pager or rendered (as presentation
> form) by a mailcap entry.

Is it necessary to send the body as an attachment in order to awaken
that mime stuff? 

When I had to pretty-font a report for management over a decade ago, I
composed it in vim, then performed a fontification in openoffice, and
gave them a M$-compatible attachment. Problem fixed.

Erik

-- 
HTML is not email, and email doesn't contain HTML, so please turn HTML
formatting OFF in your email client. We have filters in place that will
reject your message if your posting contains HTML.
   - http://gpl-violations.org/mailinglists.html

Re: How to be warned about non-existent aliases?

[Erik Christiansen]

On 25.04.17 11:16, Chris Green wrote:
> Essentially anything without an @ should be an alias, I never actually
> send mail to local (same system) destinations.

While I do send mail to myself several times per week, as paperless
Post-It notes, that would involve even less typing with a "me" alias.

As I have edit_headers set, and always enter destinations in the editor,
there is no possibility of tab-completion in mutt, for semi-manual
checking. (Though I could scrape the aliases from .muttrc with a few
lines of awk, to generate a private dictionary for vim, and then use
spellchecking to flag bung aliases. Thus a quick hack is to hit zg on
any good alias which fails spellchecking, to add it to the private OK
spell-list.)

Anyway, +1 for accepting the need for aliases for local destinations, as
the price for fumble checking in mutt.

Erik

Re: My typical .muttrc frustrations

[Erik Christiansen]

On 22.04.17 14:33, Charles E Campbell wrote:
> Hello, Erik:
> 
> I tried both mail and mailx.  Both fail silently when I attempt to send an
> email off my machine (didn't try mailx, but mail will send email to accounts
> on the same machine), although I suppose its possible they're still
> re-trying somewhere in the background and won't get a failure email for a
> few days.

Charles, I've just sent an email to myself via the ISP (the "Received:"
header lines show it went via 3 of their servers), thus confirming that
I don't have such an issue. (I'll freely admit that much of my mailx
usage is to send myself a reminder after I've shut down mutt, and can't
be bothered with entering the ISP password for fetchmail, and waiting
for things to come up.)

> That's why I had been using mutt until recently.  I have two
> potential smtp(s) targets, but neither works with mutt.  For example, both
> smtp targets fail with:
> 
> SSL connection using TLSv1/SSLv3 (ECDHE-RSA-AES256-SHA)
> digest-md5 authentication failed, trying next method
> external authentication failed, trying next method
> anonymous authentication failed, trying next method
> SASL authentication failed
> Could not send the message.

And that doesn't happen when mutt is used interactively, AIUI.
The question seems to be: What does it do in that mode, to bring up the
SSL connection, that neither mutt nor mail do in batch mode?

> Regards and thank you for looking into this,
> Chip Campbell

No worries. Unfortunately, I haven't set up any SSL for mail, so can't
shed the light of experience on the gremlins you're smoking out.

Erik

Re: My typical .muttrc frustrations

[Erik Christiansen]

On 17.04.17 22:34, Charles E Campbell wrote:
> Here's the result:
...
> Could not send the message.

Well, it's never occurred to me to pause to figure out how to use mutt
to send email on the command line, because the MUA I used before mutt
was traditional unix "mail"¹, and it is infinitely easier to just
apt-get that. A "man mail" shows that it's:

bsd-mailx - simple mail user agent

that I'm using ATM. As /usr/bin/bsd-mailx is only 92 kB in size, it
doesn't add much ballast to mutt 1.8.0 at 2.46 MB.

Mind you, it may just be that running an MTA here (postfix these days)
is what avoids your problems. That was easy to set up after the first
effort, given that I keep a few notes to avoid excessive brow furrowing
next time round.

¹ It was what we had on HP-UX and Solaris boxes back in the 1980s, and
  it still works the same.

Erik

Re: Playing nice with Outlook - setting flags

[Erik Christiansen]

On 28.02.17 12:27, Bill Starrs wrote:
> What I am looking to do is edit the headers of existing messages in my work
> Inbox to add the Follow-up Flag, and sync those changes back to the Exchange
> server with IMAP so that my flags are present in Outlook on my work machine.

OK, for post-processing old emails, you could set edit_headers in mutt,
and hit 'e' to then add the header in the editor. In vim, I'd use a
mapping to do it on a single keystroke. That's a fairly painless edit,
and perhaps simplest, unless the old emails are very numerous and in
maildir format, so you could feed a selection of them through sed or awk
to add the X-Message-Flag header in bulk.

To control what's there for editing, I have:

set edit_headers=yes
ignore *
unignore  In-reply-to References Reply-To cc To From Date Subject
hdr_order In-reply-to References Reply-To cc To From Date Subject

some just for information or deletion.

The closest received message editing usage I have is to send myself an
email as a reminder, then later edit it with updates, until it is
resolved and can be deleted/archived. There are worse places than the
primary inbox for reminders.

Erik

Re: It works if you give it a chance. [Was: Changing the reply address.]

[Erik Christiansen]

On 27.02.17 07:07, Kevin J. McCarthy wrote:
> Just to add another caution: if for some reason later on you decided to
> "set include=yes" in your .muttrc, the prompt would no longer occur and
> that leading "y" in the macro might end up sending the email!

I've taken the precaution of omitting the 'y', in favour of:
"set include=yes". (I think it's also quicker to do a d} in vim than to
respond to the include query in the generic case.)

Another data point; the reply-hook triggers fine on reply to a single
email, but tag two (even from the target sender), and it doesn't.
Checking multiple senders for a match is perhaps feature creep, I am
forced to admit. :-)

Erik

It works if you give it a chance. [Was: Changing the reply address.]

[Erik Christiansen]

On 22.02.17 18:50, Erik Christiansen wrote:
> On 21.02.17 13:28, Kevin J. McCarthy wrote:
> > 
> > You'll want to use the "push" command:
> >   reply-hook '~f x...@yyy.asn.au' \
> >  'push z...@bigpond.com'
> > 
> > *However*, this kind of thing is very delicate.
> 

With a 'y' in front of , it does actually work fine. My
mistake was expecting the reply-hook to take effect early enough to
affect the edit-headers. But the action occurs after leaving the editor.
I didn't infer that from the reply-hook text:

"19. Change Settings Based Upon Message Recipients"
...
"reply-hook is matched against the message you are replying to, instead
of the message you are sending." ...

"reply-hooks are matched before the send-hook, regardless of the order
specified in the user's configuration file."

I'll put a reminder in my own notes. It's not as easy as it used to be
to remember the details when moving rapidly from activity to activity.

So edit-to is robust enough for everyday use, it seems.

Erik

Re: Install hiccup [Was: mutt 1.8.0 released]

[Erik Christiansen]

On 27.02.17 16:49, Tim Ye wrote:
> Hi Erik,
> 
> I just tried './configure' on my Debian, no error showed up.
> 
> Have you tried:
> 
> $ sudo apt-get build-dep mutt

Bullseye! That's easier than fiddling with install paths.

The "make Install" put it in /usr/local/bin/, so I can "try before I
buy". ;-)

Many thanks.

Erik

Re: Install hiccup [Was: mutt 1.8.0 released]

[Erik Christiansen]

On 27.02.17 19:28, Erik Christiansen wrote:

> configure: error: no curses library found
>   ###

All right, some or all of the libraries mentioned in the OP are dynamic
libraries, so definitley not enough caffeine. So I'd have to apt-get
source, or snarf "GNU ncurses, ftp://prep.ai.mit.edu/pub/gnu/;, it
seems.

Ah, I got that far back with mutt 1.7.0, last year, but saw:

  
  # CAVEAT EMPTOR: `install.data' run as root will NUKE any existing #  
 
  #  terminfo database. If you have any custom or unusual entries SAVE them  #
  #  before you install ncurses.  I have a file called terminfo.custom for   #  
 
  #  this purpose.  Don't forget to run tic on the file once you're done.#  
 
  

and chickened out.

If I configure with --prefix /usr/local, and use --with-curses for the mutt
build, it can all be made to wangle together. I'll give it a try.

Erik

Install hiccup [Was: mutt 1.8.0 released]

[Erik Christiansen]

On 24.02.17 13:28, on mutt-announce, Kevin J. McCarthy wrote:
> I am pleased to announce version 1.8.0 has just been released.  It is
> available at ftp.mutt.org/pub/mutt/mutt-1.8.0.tar.gz via ftp and http.

Many thanks to all for the much valued development effort.

Unfortunately, installation of 1.8.0 is stalled here by apparent
incompatibility between Mutt and the Debian installation I have:

$ more /etc/issue
Debian GNU/Linux 7 \n \l

$ ./configure
...
checking for waddnwstr in -lncurses... no
checking for waddnwstr in -lncursesw... no
checking for initscr in -lncurses... no
checking for initscr... (cached) no
checking for tgoto... no
checking for tgoto in -ltermcap... yes
checking for initscr in -lcursesX... no
checking for initscr in -lcurses... no
checking for initscr in -lncurses... (cached) no
checking for initscr in -lxcurses... no
checking for initscr in -ljcurses... no
checking for initscr in -lunknown... no
configure: error: no curses library found
  ###

(Repeated as root, just in case, but same result.)

Maybe we should get some, then?:

$ apt-cache search libncurses
...
libncurses5 - shared libraries for terminal handling
...
libncursesw5 - shared libraries for terminal handling (wide character
support)

and:

# apt-get install libncurses5
Reading package lists... Done
Building dependency tree   
Reading state information... Done
libncurses5 is already the newest version.

That's one ncurses library available, and there's also:

$ apt-cache search ncurses
...
ncurses-base - basic terminal type definitions

which is also present and current:

$ dpkg -l ncurses-base
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture   Description
+++-=-===-==-=
ii  ncurses-base  5.9-10  allbasic terminal
 type definitions

OK, what does the old one use?

$ ldd /usr/bin/mutt | grep ncurses
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb76c2000)

Ha, let's get that, then:

# apt-get install libncursesw5
Reading package lists... Done
Building dependency tree   
Reading state information... Done
libncursesw5 is already the newest version.

Now I am beginning to run out of ideas. There's something less than
blindingly obvious afoot here ... or I need a higher caffeine to
haemoglobin ratio.

Erik

Re: Playing nice with Outlook - setting flags

[Erik Christiansen]

On 24.02.17 19:22, Bill Starrs wrote:
> One thing that I have been unable to do despite a lot of googling is
> add an Outlook "Follow-up" flag to mail items.  I can flag them as a
> priority in Mutt but this does not go back to Outlook.  Is there any
> way possible to mark a message with the "X-Message-Flag: Follow Up"
> header?

In the manual: "3.11. Defining custom headers" ; my_hdr
A folder-hook, or any other, can make addition of the header conditional
if it's not always required. (Will need a default hook to turn it off
when in another folder.)

> It would be very helpful to my workflow if I could mark important
> items in Mutt and then be able to act on them when I am back in the
> work environment.

That desirable configurability is where mutt really shines.

Erik

Re: Changing the reply address.

[Erik Christiansen]

On 21.02.17 13:28, Kevin J. McCarthy wrote:
> On Tue, Feb 21, 2017 at 05:27:55PM +1100, Erik Christiansen wrote:
> > reply-hook '~f x...@yyy.asn.au' \
> >'z...@bigpond.com'
> 
> You'll want to use the "push" command:
>   reply-hook '~f x...@yyy.asn.au' \
>  'push z...@bigpond.com'
> 
> *However*, this kind of thing is very delicate.

That is becoming increasingly evident. With a 'y' immediately before the
first '<', the improvement is triggering on the x...@yyy.asn.au, and
pushing the 'y', as evidenced by inclusion without the prompt which
occurs for any other reply target. But, sadly, no  is done, and
all 4 fields of the From: header are transferred to To:, as if nothing
other than the 'y' were pushed.

> Any prompts that occur after the hook is set will try to read from the
> pushed input, for example $include should either be set to yes/no or
> you'll need to add a "y" at the beginning of the push string for that
> prompt.

Tried "set include=yes", but that also fails to . I'll try to
upgrade mutt, something which has languished on the ToDo list for a long
time. (Too many irons in the fire.)

Thanks for taking a nibble at it, Kevin.

Erik

Changing the reply address.

[Erik Christiansen]

My brother sometimes sends emails from work, but often runs days behind
reading replies. (Everyone just has to wait.) If I reply instead to his
home address, it's straight through. So I thought I'd try to tweak the
following:

Way back on 27.04.09 16:57, Kyle Wheeler wrote:

>  send2-hook '~C helpdesk@mycompany' \
>  'helpdesk@mycompany'

to:

reply-hook '~f x...@yyy.asn.au' \
   'z...@bigpond.com'

That triggers, but gives an "unknown command" error on the action.
The  appears in Table 2.12, and the rest is just a copy of
Kyle's example, so I'm a little short on things to tweak to make it go.

When I substitute send2-hook or send-hook for reply-hook, there is no
error, but the To: address is unaltered, i.e. the hook does nothing at
all.

Has anyone made something like this work?

Erik

Re: mutt+vim line-breaking strategies

[Erik Christiansen]

On 18.02.17 21:54, Xu Wang wrote:
> Do you line-break your emails? Do you use flowed text? I am curious
> what the most common and recommended workflow is.

As it is the long established email standard that lines be 72 characters
to allow a couple of levels of "> " quoting in replies, without the need
to reflow, for mutt I have this in .vimrc:

" Mutt:
au BufNewFile,BufRead   ~/Desktop/mutt-*   call Set_for_mutt()

function! Set_for_mutt()
setlocal textwidth=72 foldmethod=manual
setlocal formatoptions=qrjt

" Change subthread Subject:
noremap  ^[gg/Re:^Mce[Was^[A]^[0Wi

" CheckAttach.vim is a filetype plugin.
filetype plugin on   

Of course, vim respects multiple levels of "> " quoting when reflowing a
paragraph with gq}, but we can't assume that everyone replying has the
same facility, thus 72 characters rather than 80.

The topic was recently discussed at some length, as recorded in the
archive.

Erik

Re: Muttrc example needed POP3/SMTP

[Erik Christiansen]

On 04.02.17 17:04, sunrise wrote:
> 
> Are there any suggestions for which MTA would be most suitable for
> this purpose (sending queued messages on a system that is not online
> when composing messages)?

They would all handle that, straight out of the box. Mail spooling is a
basic MTA function. (I remember looking at great piles of backed up mail
on a company-wide mailserver which used sendmail and uucp over dial-up,
back in the early 1990s, when the internet in Australia had only spread
to universities and companies.)

I have ADSL, but may not remember to turn on the modem before composing
some emails. Postfix will spool them, and automatically send them after
the ADSL link comes up. The others will too.

Maybe look up the manual on the preferred MTA candidate, and check for
an easy to understand command to flush the queue, in case you ever need
to manually free a logjam for some reason, and you want to get e.g. a
resume out fast.

Erik

Re: Muttrc example needed POP3/SMTP

[Erik Christiansen]

On 03.02.17 09:47, Chris Green wrote:
> ... and if you're on a distribution where Postfix is the standard
> that's also pretty easy to set up.  I personally prefer Postfix from
> the ease of configuration point of view.

+1

(It also has a Sendmail compatibility interface, so that we old folks
could move over painlessly. But now my muscle memory is Postfix oriented.)

> I use Postfix and both send and receive mail using SMTP as my desktop
> machine is on all the time.  Thus I have no need for POP3/IMAP mail
> collection.

As my machine is shut down each night, I use fetchmail to bring mail in
via POP3. It has served me well for several decades now.

Erik

Re: display_filter and ex

[Erik Christiansen]

On 01.02.17 00:56, Andreas Doll wrote:
> TL;DR
> Has anyone managed to use ex in conjunction with display_filter?
> 
> 
> I write emails using vim, which provides the handy function gggqG. This
> function reformats text such that it doesn't exceed (say) 72 characters.

The ex exercise is intriguing, but one can have approximate equivalence
with:

a) Reading emails as delivered, in an xterm wide enough to accommodate
   80 or 90 character lines, without inconvenience.¹

b) When trimming quoted text in Vim, gq} can be repeated on each
   retained paragraph with overlong lines, with quoting (even
   multilevel) well handled, as you describe. A longer reformat seems a
   temptation to fullquoting?

   With gq} mapped to e.g. ^W, it's only necessary to whack ^W three
   times to format three paragraphs.

Dunno if this alternative appeals - after all, it unfortunately obviates
the need to play with display_filter. ;-)

¹ I do have:
set smart_wrap  # Wrap
set wrapmargin=10   # long lines. 
unset markers   # No '+' email line continuation crap.
# Busts URLs!

Erik

Re: best practices answering multiple mails (at once?)

[Erik Christiansen]

On 08.11.16 19:47, Simon Ruderich wrote:
> On Tue, Nov 08, 2016 at 10:28:46AM +0100, nfb wrote:
> > Oh thank you all guys for your answers. Let me practice what i
> > learnt then... this kinda seems the appropriate use case too :)
> 
> In this case it was "problematic" for me, because I didn't notice
> that you answered my mail as well, as mutt didn't show this
> message as reply to my mail.

Ah, that's a disappointment. I had hoped for:

On 08.11.16 23:57, Erik Christiansen wrote:
> Here it was displayed as a reply to my post. If Cameron and Simon's
> mutts display it under their post, then mutt is doing very well indeed.
> (Convenience is maximised, and confusion is negligible - within a
> thread.)

But locally originated Message-Ids are not easily identified without
adding a cache. And how long would you keep it? (It could be done with a
procmail rule checking for " wrote:" in the body, but that
relies on the sender not fiddling with attribution.)

What I've done here, to make it non-problematic for Simon, despite
quoting two posts, is delete my Message-Id from the In-Reply-To
header, made easy by having edit_headers set, with some header weeding.
Admittedly that wouldn't have worked for my earlier triple reply.

Erik

Re: best practices answering multiple mails (at once?)

[Erik Christiansen]

On 08.11.16 10:28, nfb wrote:
> On Tue, Nov 08, 2016 at 02:08:55AM +0100, Simon Ruderich wrote:
> > However in the thread view the resulting mail will only appear as
> > reply to one of those mails (not sure if this is a limitation of
> > mutt or the in-reply-to header).
> 
> I dont know whether it's a mutt limitation, but iirc this is the
> behaviour on other mail clients too.

nfb, your triple-reply carries this header:

In-Reply-To: <20161107230059.ga19...@cskk.homeip.net>
<20161108010855.dfy5bwr7jcn4c...@ruderich.org>
<20161108011542.GA3594@ratatosk>

I.e. it is flagged as a reply to all three correspondents, and it is the
recipient's MUA which is stuck with deciding where to display the post
in a thread tree. IME it would only be if the poster had chosen to grab
posts from multiple subthreads that confusion would arise.

Here it was displayed as a reply to my post. If Cameron and Simon's
mutts display it under their post, then mutt is doing very well indeed.
(Convenience is maximised, and confusion is negligible - within a
thread.)

Erik

Re: best practices answering multiple mails (at once?)

[Erik Christiansen]

On 08.11.16 10:00, Cameron Simpson wrote:
> On 07Nov2016 22:47, nfb  wrote:
> >here i want to submit to you some doubts I have when replying to some
> >mails. I may be a little OT, but i'd like to hear from you wether
> >answering to multiple emails at once, quoting text from them, is a
> >good practice, and how you accomplish that in mutt. Otherwise what is
> >the recommended way to answer multiple messages in the same thread?
> >I tried searching online but it seems a very particular topic, so I
> >couldn't find much.
> 
> It is pretty rare, but when I need to do it I tag all the source
> messages and hit 'g' (group-reply), and then pay careful attention to
> the to/cc list.

+1 (but I always hit 'L')

It can work well on a busy thread, both to avoid inflating the thread
with multiple fragmentary replies, and to put all of the information
regarding several facets in one place, for the record. (I use it only
very occasionally.)

It can be advantageous to swap the order of the quoted messages for a
more logical flow in the reply, and trimming of the quoted text is even
more important in the case of several long messages.

Erik

Re: Send mail to an 'address group'

[Erik Christiansen]

On 13.09.16 12:08, mimosinnet wrote:
> When the members of the group CoordsM change, I have to change the
> alias.
> 
> Is there a way I can use the definition of the "Address Groups"
> (http://www.mutt.org/doc/manual/#addrgroup) to be able to define an
> alias (http://www.mutt.org/doc/manual/#alias).

Defining group membership the other way, using the "group" command,
would offer the opportunity to do that, _if_ mutt had a -group_alias
option on the group command, for adding the needed group alias.
But it doesn't, and you'd still be editing in two places, anyway.

I've not tried to make the group and group_alias names the same, to ease
the task of e.g. an awk script synthesising the group's alias from the
"alias -group" lines. Leaving it as is, I figure one would need a
linking comment line, e.g.:

# group_alias CoordsMaster CoordsM

placed _before_ the first alias line using either name.

Then a script something like:

#!/bin/bash

gawk '
$2 ~ /group_alias/   { alias_groups[$4] = $3 ; group_aliases[$3] = $4 }

$1 ~ /alias/ && $2 ~ /-group/   {
   if ($3 in alias_groups)
   {  i = alias_groups[$3]
  alias_lists[i] = alias_lists[i] ", " $4
   }
}

$1 ~ /alias/ && $2 !~ /-group/ {
   if ($2 in group_aliases) printf("%s %s %s\n",$1,$2,substr(alias_lists[$2],3))
   else print
   next
}
   
   { print }  # Print all lines not rewritten.

' ~/.muttrc > /tmp/muttrc


does the trick for me. To use:

$ muttalgrp  # Or whatever it should be called.
$ diff ~/.muttrc /tmp/muttrc # Check shows one line updated, here.
$ mv /tmp/muttrc ~/.muttrc   # You could back-up the old one first.

Caveats:
1) This was quickly cobbled together to see what it'd take to do the job.
   It has only been lightly tested.
2) It catches the required alias lines, and those without -group, but
   not present in group_aliases, but there might be some .muttrc idiom
   which isn't covered.
3) It ought to work for multiple groups in the .muttrc, but it's only been
   tested on one.
4) It doesn't suit my use-case, where not every member of the group
   is allowed to be in the group alias, as the group included in replies
   is a subset of the receipt group. That could perhaps be fiddled with
   either multiple groups or group aliases.

Re: add the content of another email to new message

[Erik Christiansen]

On 23.08.16 19:47, Jethro Tull wrote:
> So I could save and close the current composition,

It is elementary to postpone the composition if desired. (See the
manual) A collection of postponed messages presents as a message index,
just as for any other mail folder. You can work on many of them in a
day.

If, instead, the composition is completed and sent, then automated
default or ...-hook saving is provided by mutt. (See the manual)

> then from that point I would need to browse my emails and edit the
> ones I want to select what I want and dump the selection into the
> email I was composing before without a copy/paste process

The task you initially described is just that, but it is much simpler to
collect the input messages in the composition (automatically done by
mutt when they are tagged and then a ";r" reply is chosen. (The question
presented will be answered in the affirmative, just by hitting return.)
Please read again the several simple available process flows, described
upthread. And try them.

>which would complicate things if I need the content of many emails. 

Simple repetition is not complication; it is just tedium. (See below for
the case where they're not all in one mail folder. That is a small
complication, readily dealt with.)

> The tricky thing I'm searching about is how to select the right file which
> corresponds to the email I was composing. I could of course browse the
> files in my maildir repo from within vim,

No, you are working too hard to make things difficult for yourself. The
optimal method described upthread involves tagging the emails in mutt,
so they are all popped into the vim session for you, by a ":r". Normally
the emails are in the one (e.g. list-related) mail folder, so that works
well. But what of a worst-case scenario, where you need to pull together
messages from a number of mailboxes. It is still optimal to use your MUA
(mutt) for mail, because oddly enough, that's what it's for. All you
need to do is browse the mail folders in mutt, and 'C' copy the chosen
messages to e.g. /tmp/ooh-de-elephants. When they're all there, 'c'
change folder to /tmp/ooh-de-elephants, and tag all the messages in the
index with "T~A", then ";r" to reply to them all.

Now they're all in your vim session, and it can be postponed (by mutt)
if that's all you can manage before lunch. And when you resume the
composition, everything's there. Nothing is needed but the editing and
composing. (When using that method, d} (in vim) make very light work of
eliding message headers en mass. Each message can be trimmed in
seconds.)

And, to repeat, it's even simpler if the messages are all in one
mail folder, as they can all be found in the one mutt index, and be
tagged there.

> but it doesn't look like a right way

Indeed. Trying to do things backwards isn't optimal. Re-reading the
methods described upthread, and trying them is advised. 

> because, first, the files in the maildir repo seem to be named
> randomly, second, what if my emails were stored in an mbox format?

That's not over-analysis, it's vague speculation. It has no purpose.
When you browse a mail folder in mutt, it makes no difference which
storage format is used. The index is the same in each case.

Goal-oriented thinking involves considering what _is_ available, and
trying out these methods which do work.

> It's a complicated thing because edition is made from within vim and
> email browing is done with mutt.

No, that is not the reality. ;-)
The reality is that it's a simple thing because editing is in vim and
browsing is done with mutt. Try the described methods and you will learn
the truth of that.

If you can stop trying to eat soup with a fork, and use the offered
spoon, success will follow.

Erik

Re: broken date with LANG=xx_XX.UTF-8

[Erik Christiansen]

On 19.08.16 07:39, Matthias Apitz wrote:
> If I unset it in ~/.muttrc and run
> 
> $ LANG=es_ES.UTF-8 LC_ALL=es_ES.UTF-8 LC_TIME=es_ES.UTF-8 mutt
> 
> it gives the month name as 'Aug', which is not correct.

Try:

$ export LANG=...

Erik

Re: mutt, vim, and autowrapping replies

[Erik Christiansen]

On 19.08.16 12:39, li...@rickv.com wrote:
> I found the answer here:
> http://www.mdlerch.com/emailing-mutt-and-vim-advanced-config.html
> 
> I'm using it now; it works well. Except,
> 
> On Fri, Aug 19, 2016 at 02:14:15PM +1000, c...@zip.com.au wrote:
> >One caveat is that in format=flowed a line with no trailing space
> >is actually not meant to be reflowed. Such as lines of code.
> 
> I'm not sure how it handles this, the way it is. It'll probably need
> tweaking. It's already butchered my sig.

Urrg. If a complete solution evolves, I'd consider it. But in the
interim vim fully honours "> > > " style quoting when reflowing a
paragraph with gq}, which I've mapped to ^W, allowing reflow of three
paragraphs with ^WWW. That is cheap enough that full automation may
become a backwards step on encountering an occasion when it's not
desired.

As the reflow leaves the cursor after the reflowed paragraph, that is
the time to decide whether to reply to the text - and if not, then hit
d{ to delete the bumpf not relevant to the reply being composed. If the
need for explicit reflowing of quoted text encourages more assiduous
pruning in lieu of profligate over-quoting, then let's keep it manual, I
say.

Erik
(Where's my tin hat & flak jacket?)

Re: mutt 1.7.0 released

[Erik Christiansen]

Kevin,

Many thanks for your effort to keep us flea-free.
This time I do plan to upgrade.

Erik

Re: add the content of another email to new message

[Erik Christiansen]

On 16.08.16 19:58, Jethro Tull wrote:
> I'm using vim as editor in mutt. I would like to find a way to dump
> the content of another email or part to a new message while being
> composed. Of course without running a new instance of mutt.

The most convenient technique for including parts of other/multiple
emails in a new composition varies with use-case. If the text is not to
be quoted, but re-used as original text, then there are several methods:

a) Within vim, use ":r filename" to include the file containing the
   desired email, then edit. If there are thousands of emails in the
   mailbox, then you're not holding your mouth right, and will have to
   delete large slabs of text, but cpu cycles are cheap.

b) Within vim: ":w", then ": e filename", then find the text you want,
   and yank it, "^" back to the composition, and paste.

c) If desiring to make it a bit more complicated, in a separate instance
   of vim, ": e filename", then find the text you want, and highlight it
   with the rodent. In the vim instance within mutt, you'll be in insert
   mode, and move the cursor into that window, then whack the middle mouse
   button.

Alternatively, when needing to quote parts of multiple posts for use in
a single reply to them all, it is convenient to tag them, perform a ';'
reply, then edit each of the quotes in vim within mutt, replying in-line
to the parts retained.

That use-case can be abused by quoting an email of your own, then
deleting the "> " quotation marks, e.g. with !Gs/^> //
That presupposes that your source email is in the same mail folder,
which is a limitation - but the method is very quick.

That's probably enough options, without looking for obscure methods.
None of them require a new instance of mutt.

Erik

Re: need some help about organize message in mutt

[Erik Christiansen]

On 06.08.16 06:56, Patrick Shanahan wrote:
> 
> You will forgive "senior" memory :)

Am bailing out the same canoe daily, here.
The stuff which has moved from memory to "forgettery" is horrifying.
The only saving grace is that most of it comes back with a peek at old
notes, and a bit of keyboard thumping.

Erik

Re: need some help about organize message in mutt

[Erik Christiansen]

On 04.08.16 09:27, Patrick Shanahan wrote:
> * Gabriel Philippe <gabri.phili...@gmail.com> [08-04-16 09:25]:
> > On Tue, Aug 2, 2016 at 1:00 PM, Erik Christiansen
> > <dva...@internode.on.net> wrote:
> > > Subscribing to the procmail mailing list would help while learning.
> > 
> > Does it still exist? procmail.org is down for several months.
> > 
> > >From the manual page of procmail: "There exists a mailinglist for
> > questions relating to any program in the procmail package:
> > <procmail-users-requ...@procmail.org> for subscription requests.".
> > Hoewever:
> > 550 5.1.1 <procmail-users-requ...@procmail.org>: Recipient address
> > rejected: User unknown

Ah, yes, a DNS "dig" on procmail.org fails, and a visit to:
http://www.procmail.org/   gives:
"Site hosting in transit, information will be back up shortly."
However, from the headers of a recent list post we have:

List-Subscribe:
<http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail>,
<mailto:procmail-requ...@lists.rwth-aachen.de?subject=subscribe>

In contrast, that http link is up, so either method should work.

> I still receive mail from the procmail list, several in the last two
> weeks, but few...

That's curious, as the last message in my procmail inbox is from June
3rd. My mail log also shows none more recent, so it's not just that I've
deleted more recent arrivals.

Viewing the archive by date:
http://mailman.rwth-aachen.de/pipermail/procmail/2016-June/date.html
confirms that the most recent post is Fri Jun 3 00:56:14 CEST 2016.

Gabriel, it is a low-traffic list, so a quiet period does not confirm
that the list is down. Would you like to post a query, then we'll see.

Patrick, could you please confirm newer traffic? As a long-term
subscriber, I'd be irked by having been spontaneously dropped off.
There's then also be the archive to be fixed.

Erik

Re: need some help about organize message in mutt

[Erik Christiansen]

On 02.08.16 08:05, Yubin Ruan wrote:
? Attribution lost upthread:
> > Normal practice for mutt users is to file messages with a separate
> > program as they are collected. This works best with local storage:
> > we collect our email from the server with POP or IMAP and store in
> > local folders on our computers.  We can walk you through setting up
> > such an arrangement if you decide you want to go this way.
> 
> If there's some common practice I would really appreciate to hear some. 
> Figuring
> it out myself is kind of hard.

Hey, this is *nix. It's only when someone says "You're all individuals."
that any of is likely to pipe up from the back with "I'm not!". ;-)

Googling for "procmail howto" showed more help than an average
old-school user would normally need, first up.
But there is much procmail config guidance in the procmailrc manpage.
(And it's first line says: "For a quick start, see NOTES at the end of
the procmail(1) man page." That shows how it might be automatically
invoked.
There's also "man procmailex" for useful examples.
Subscribing to the procmail mailing list would help while learning.

While learning, it might also be an idea to use an initial copying
recipe to duplicate all incoming mail in a backup mailbox, since it is
possible to lose mails by writing a faulty delivery recipe. (Look for
"safety net" in "man procmailex".

The manpages seem to be included in the procmail .deb package - at least
I don't see a procmail-doc package to bother with.

Erik

Re: need some help about organize message in mutt

[Erik Christiansen]

On 01.08.16 10:42, Thomas Schneider wrote:
> Yubin:
> 
> > How can I have that Thunderbird message filtering in mutt?
> 
> I have been using procmail to filter mail into different mail boxes.
> Then I look at those boxes with mutt under a script that opens each
> one.  This allows me to categorize my junk mail and then move them to
> my main mail box if I want to keep one.

There's no need for any script. Once procmail has sorted incoming mail
into a bunch of mailboxes, e.g. one per mailing list, etc., then in
.muttrc, something like:

mailboxes +/family_u /var/spool/mail/erik +/avr_gcc_u +/vim_u +/mutt_u
mailboxes +/procmail_u +/todo +/cnc_linux_u +/luv-main +/binutils_u
mailboxes ~/postponed  # So it's accessible in the 'y' list.

Now mutt presents the highest priority mailbox which has new mail, and
'c' changes folder to the next highest with new mail, skipping any stale
ones in between.

I have some simple spam filtering, and should maybe add +/spam as the
last mailbox, as a reminder to look in there once in a blue moon for
false positives.

The stuff I want to keep goes into ~ 1200 categorised mailboxes.

Erik

Re: Three newbie questions

[Erik Christiansen]

On 08.07.16 00:46, Alasdair McAndrew wrote:
> 1. When I send an email, no matter from what account, a copy always
> ends up in the Inbox of my default account.  How can I ensure such a
> mail ends up in the Sent folder of its account?

I'd look for a "set record" statement in .muttrc, and replace it
with:

set record="~/mail/Sent"

or whatever the path to yours is.

Several questions in one mail is fine, so long as readers are curious
enough to delve past the non-specific subject line, which admittedly
does tempt with the prospect of low-hanging fruit, and so may work well.
Heck, some respondents may even have time/experience to answer more than
one of them. ;-)

Erik

Re: How to color diffs in a patch-mail?

[Erik Christiansen]

On 20.06.16 14:01, Matthias Beyer wrote:
> can someone tell me how to color diffs in a PATCH mail when viewing 
> the mail contents with mutt?
> 
> Is it even possible?

Dunno. Once a patch has been delivered, I figure we've left the email
world. But you could:

set editor=vim

hit 'e' on the email, and then use vim's syntax highlighting do go to
town. A google for "vim syntax diff" seems to throw up all sorts of
stuff, including mimicking the colours of a git diff.

Erik

Re: Lines beginning with From are not escaped in $record

[Erik Christiansen]

On 03.06.16 17:22, Xu Wang wrote:
> Interesting. To reproduce what i see, you can do following steps:
> 
> 1. move the file (temporarily but be sure to back up) ~/sent
> 2. in mutt, do
> set record="~/sent"
> 3. send an email with "From " in the body
> 4. Open in vim or in mutt+vim ~/sent file.
> 
> I think you will then see that no escape is there.

Having used mutt to send one of the test emails, it was enough to just
look in ~/mail/sent. Like you, I haven't seen any mention in the mutt
manual, of its interpretation of mbox format. But the mbox manpage does
say:

| Besides MBOXO and MBOXRD there is also MBOXCL which is MBOXO with
| a "Content-Length:"-field with the number of bytes in the message
| body; some MUAs (like mutt(1)) do automatically transform MBOXO
| mailboxes into MBOXCL ones when ever they write them back as MBOXCL
| can be read by any MBOXO-MUA without any problems.

How the last statement can be logically supported eludes me, as a regex
search works with MBOXO, but fails with MBOXCL, disproving it instantly.

It does, though, neutralise any rational aversion based on quoting, to
use of mbox format together with mutt, if the MDA also uses MBOXCL.
(I will admit to not having found anything in man procmailrc to allow
one to make that tweak.)

Erik

-- 
The wonderful thing about standards is that there are so many of them.
- Andy Tanenbaum

Re: Lines beginning with From are not escaped in $record

[Erik Christiansen]

On 29.05.16 17:07, Xu Wang wrote:
> Interesting! So the term is "From munge".

"man mbox" is more formal, referring to "quoting schemes", but either
term serves, I figure.

> So I guess the format of mbox that mutt uses does not from munge. it
> must be then than that the format mboxcl2 is being used, which does
> not from munge and relies on Content-Length:. Can anyone confirm? I
> searched for mboxcl2 in man muttrc but no instance.

erik@ratatosk:~$ mail -s "From test" erik
>From today, it is all future.
>From Erik
Cc: 
erik@ratatosk:~$

When that post is viewed in mutt, and in vim within mutt, the body of
the received email is:

>From today, it is all future.
>From Erik

That is consistent with the MBOXO/MBOXRD quoting scheme.

Erik

Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8

[Erik Christiansen]

On 03.06.16 10:32, Matthias Apitz wrote:
> I'm on FreeBSD and do compile all from sources (the so called ports
> collection). mmencode comes from:
> 
> $ which mmencode
> /usr/local/bin/mmencode
> $ pkg which /usr/local/bin/mmencode
> /usr/local/bin/mmencode was installed by package metamail-2.7_11
> 
> $ fgrep -A1 MASTER_SITES ports-r414411/*/metamail/Makefile
> MASTER_SITES= http://ftp.funet.fi/pub/unix/mail/metamail/ \
>   ftp://ftp.research.telcordia.com/pub/nsb/
> 
> I don't know if this would compile straight forward on your system.

A previous build of the 2.7 version, some years ago, worked fine, but
the link I had kept: http://kb.iu.edu/data/data/aibt.html is now a 404,
which inclines me to go with Debian's decision to obsolete the package
on the basis that it isn't maintained. (Better to invest in remembering
replacement utilities with a greater future availability, I think.)

Erik
(who remembers when uuencode was the go-to decoding utility.)

Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8

[Erik Christiansen]

On 03.06.16 10:52, Christian Brabandt wrote:
> 
> An alternative might be qprint (package qprint)

Indeedy! :-)

Thank you Christian. I've made a note of that.
(Stuff from many years ago now sticks better than new stuff. :(

Regards,
Erik

Re: Convert ascii UTF8 code (in mutt "to:" header) to real UTF8

[Erik Christiansen]

On 03.06.16 08:45, Matthias Apitz wrote:
> $ echo 'Ker=C4=B1ko' | mmencode -u -q
> Kerıko
> $ echo 'Ker=C4=B1ko' | mmencode -u -q | od -tx1
> 0004b  65  72  c4  b1  6b  6f  0a
> 010

Matthias, mmencode looks very useful, but I'm not able to find it on my
debian install, and apt-search doesn't do any good either. We used to
have mimencode, but that was obsoleted years ago. I tried munpack, but
that doesn't seem to make any attempt to handle mime fragments.
Any clue on where mmencode might be snaffled would be very handy.

Erik

Re: Feature request

[Erik Christiansen]

On 04.05.16 15:51, Walter Alejandro Iglesias wrote:
> +1 requesting this feature:
> 
> http://unix.stackexchange.com/questions/47773/rebinding-clear-prompt-in-mutt

Yes, that would be wonderful. The ^G aberration is a mindbender.

> All command line Unix-like system applications should support vi as well
> as emacs key bindings.

The "map Escape in the terminal" work-around, described at the link,
would seem to be a non-starter, since it would completely muck up vim/vi
when used as editor in mutt.

Erik

Re: How to move to a specific message or to the end in a long list?

[Erik Christiansen]

On 01.05.16 12:54, Chris Green wrote:
> I (rarely) have a long message list of some hundreds of messages.
> This occurs when I'm looking at old mailboxes, archives and similar. 
> 
> How does one simply move to the last page/message or to a specific
> message number?

To go to e.g. message 2144, type in 2144, and see what happens. ;-)

For going to the first/last message in a folder, the / keys
suffice. 

Beyond that, for speedier moves than /, ^P/^N are good for
flitting by thread.

Erik

Re: group mailings with blind cc - RTM

[Erik Christiansen]

On 16.04.16 14:59, Jon LaBadie wrote:
> > Next step was to set up a send-hook on the tfccc email addr.
> > This would setup "my_hdr Bcc:" to be the list of recipients,
> > or later perhaps a mutt group alias for the list.  I've done
> > similar settings before, but not for the Bcc: header.
> > 
> > This step doesn't work.  Either nothing gets added or the
> > list gets added to the To: header.

...

> So it appears you can't change the recipients from within a send-hook.

Nor with a reply-hook or message-hook, AFAICT.

> I compose in vi, so I'll just append a group alias to the Bcc line.
> I was simply trying to automate that step.

A file, e.g. drafts/tfccc, could be a template, including a long Bcc, a
default Subject, default body, and any action points open from the last
session. (OK, getting carried away here, but I've found that useful for
meetings.)

With edit_headers set, a ":r drafts/tfccc"in vi/vim will place the whole
box and dice more cleanly if invoked in a macro which deletes the
default headers first.

The greatest risk with that much automation is forgetting to update the
meeting date.

Another option is an autocommand which defines a key mapping which
inserts the Bcc:, but only when editing a mutt tmpfile. (Lets you use
the key in other ways outside mutt edits.)

Erik

Re: How do you survive without notmuch?

[Erik Christiansen]

On 12.04.16 13:05, Derek Martin wrote:
> On Tue, Apr 12, 2016 at 05:28:08PM +1000, Erik Christiansen wrote:
> > The really big benefit of the Unix approach is that the same utility
> > know-how can be applied to every problem, as it is only the mix of
> > utilities used, and their parameters, which vary. 
> 
> The downside is that typical users don't want to learn all those
> tools, and by and large have no reason to.  They use the web and
> e-mail, and very little else.

Yes, what could be inferred from your first reply is now explicit.
May your typicality serve you well, and the rest of us tolerate what the
other has learned first and uses best.

Erik

-- 
The ultimate barrier is one's viewpoint.
  - Terry Pratchett, "The Dark Side of the Sun"

Re: How do you survive without notmuch?

[Erik Christiansen]

On 11.04.16 11:11, Derek Martin wrote:
> On Mon, Apr 11, 2016 at 10:13:06PM +1000, Erik Christiansen wrote:
> > In the latter half of several decades of software development, I took to
> > heart "Unix _is_ the IDE". Similarly, there's no need for mutt to do
> > more than be a good MUA, as perfectly good search capability pre-exists.
> 
> But you must see the flaw with this approach:  It requires every user
> to make efforts to integrate their own solution for searching for
> their mail--a task that seems (to me) very obviously part of what
> any typical user would want to do, as part of handling their mail.  As
> such, doesn't it make sense that the MUA have good searching
> capabilities built in?  Doing so saves a MASSIVE amount of work, in
> man-hours.

Whether that's an attempt at humour, or just late for April 1, eludes
me. The flaw with the postulating paragraph is that there is no need
for integration of "own solution for searching". That is already
provided by Unix - for free, as is. As a consequence, the theory that
there might be "a MASSIVE amount of work" is purest fantasy. I have done
_no_ substantial work, as 'perfectly good search capability pre-exists'.

> This is where the Unix Philosophy falls down, IMO.  And don't get me
> wrong--I'm a fan.  But no solution is the right solution for every
> problem.

Compatible cooperating utilities always beat competing and often
conflicting monoliths, in my several decades of experience. The
flexibility of combining coherent capabilities to construct an
application-specific solution cannot be matched by a user-restricting
monolith with a limited set of fixed actions.

Your own words make that case for me. No monolith "is the right solution
for every problem." That is why a swarm of well-understood smaller
combinable utilities is always more flexible, and better able to handle
a large variety of problems.

The really big benefit of the Unix approach is that the same utility
know-how can be applied to every problem, as it is only the mix of
utilities used, and their parameters, which vary. With the monolithic
approach, the user has to learn a different set of levers to wrangle for
every monolith allowed on his system. That can be a massive amount of
trial-and-error climbing of learning curve - a completely unnecessary
waste of time.

Erik

-- 
The ultimate barrier is one's viewpoint.
  - Terry Pratchett, "The Dark Side of the Sun"

Re: How do you survive without notmuch?

[Erik Christiansen]

On 05.04.16 12:47, Xu Wang wrote:
> I am so used to using notmuch integrated into mutt (via mutt-kz), that
> I would like to be able to understand how someone does *not* use
> notmuch. How do you search for a certain message? Is it simply a
> matter of the following?

Deleting around 90% of list traffic makes searching faster.

Organising what is retained, according to subject is an even greater
accelerator:

$ ls -1 mail/* | wc -l
1211

On the rare occasions I'm not sure where to look, grep always quickly
delivers the goods for me. It's generally not necessary to search all
1211 mailboxes, e.g.

$ grep foo mail/mutt_* > /tmp/matches

Opening /tmp/matches with vim, I can then use gf on likely candidates.

In more than a decade of this efficient practice, I've had not much
reason to seek any alternative. Just once it seemed to fail, until I
broadened a limited search, as above, to scan all files. I had archived
the post under a more relevant topic.

A simple but useful aid has been the shell function:

mls () 
{ 
ls -xF ~/mail/*$1*
}

Now any part of a subject name finds all related collections:

$ mls security
/home/erik/mail/cnc_linux_security/home/erik/mail/linux_security
/home/erik/mail/linux_security_hints  /home/erik/mail/postfix_security
/home/erik/mail/ubuntu_security

In the latter half of several decades of software development, I took to
heart "Unix _is_ the IDE". Similarly, there's no need for mutt to do
more than be a good MUA, as perfectly good search capability pre-exists.
(For slightly faster searches, fgrep, and for modern regex, egrep.)

Erik

Re: omit empty mailboxes from list

[Erik Christiansen]

On 27.03.16 21:05, Erik Christiansen wrote:
> That's not what happens here, I hit 'c' and mutt immediately offers the
> mailbox with new mail which appears highest in the (one or more)
> "mailboxes" lines in my .muttrc.

Jon, if mutt isn't detecting new mail in the delivery mailboxes, then
it may be necessary to:

set check_mbox_size# Set only if new mail detection is unreliable
   # or doesn't work.

> If the use-case _must_ be "NOT empty", then just use the mailbox file
> format, rather than maildir. IIRC, a mailbox file from which all mails
> have been deleted, is also deleted. A non-exsistent file can hardly be
> listed by 'y'.

On reflection, that'd need:

set save_empty=no   # So empty mailboxes disappear.

Erik

Re: omit empty mailboxes from list

[Erik Christiansen]

On 26.03.16 15:10, Jon LaBadie wrote:
> I can see what you both are referring to.  There are big differences
> between 'c' and 'y' for my work style.  First, 'y' shows the files
> defined by the "mailboxes" parameter, the ones I'm looking for.  In
> contrast, 'c' shows the files defined by the "folder" parameter which
> in my case is not the receiving mailboxes, but the previously saved
> mail in ~/Mail (about 800 files). 

That's not what happens here, I hit 'c' and mutt immediately offers the
mailbox with new mail which appears highest in the (one or more)
"mailboxes" lines in my .muttrc. I.e. it not only serves as a serialised
version of the 'y' list, restricted to those with new mail (your
specified use-case), but also prioritises the list in the order given in
the "mailboxes" parameter. (Bonus points for that!)

E.g.: Send myself a test mail. Now hitting '.' for a quick check shows:

"New mail in /var/spool/mail/erik"

And hitting 'c' prompts:

Open mailbox ('?' for list): /var/spool/mail/erik

If another delivery mailbox appears earlier in "mailboxes", and has
mail, it'll take precedence. If no mailbox is proffered, then there is
no new mail. (As '.' would then confirm.)

Are you hitting '?' to go to the 800 file list?

> Another difference, 'y' immediately goes to the index where 'c' goes
> to a prompt on the status line with a suggested path.  That is where
> the '-' and up/down arrows can be used or a '?' entered to get to the
> index.

Used with a "mailboxes" parameter, 'c' automates the use-case you're
trying to achieve manually. (And very usefully adds priority)

> All useful learning thank you.  But I'll ask my original query again.
> 
> Is there a way to have the index shown by the 'y' command limited to
> those files that are NOT empty?

Not empty, or not containing new mail? I leave some read mail in
incoming mailboxes, such as earlier posts in this thread, until the
thread traffic peters out. That makes it easier to tag several posts, as
I have done here, to quote in my reply, using ";r" or ";L". There's no
need to have such a non-empty mailbox served up if there's no new traffic.

Once the thread is dead, useful posts can be archived, the rest deleted.

If the use-case _must_ be "NOT empty", then just use the mailbox file
format, rather than maildir. IIRC, a mailbox file from which all mails
have been deleted, is also deleted. A non-exsistent file can hardly be
listed by 'y'.

On 25.03.16 13:37, Will Yardley wrote:
> 
> If you define mailboxes that you expect *incoming* mail in via
> 'mailboxes' (e.g., mailboxes +foo, or mailboxes +foo*), 'change-folder'
> (bound to c by default, I believe), will cycle through mailboxes with
> new mail in the order they're defined.

That's the mutt way of handling Jon's use-case. No lists to muck with;
it's just automated.

Erik

Re: omit empty mailboxes from list

[Erik Christiansen]

On 26.03.16 10:02, Christian Ebert wrote:
> * Erik Christiansen on Saturday, March 26, 2016 at 19:54:16 +1100
> > To return to a mailbox which was read earlier in the mutt session,
> > in the index, press 'c' to initiate a mailbox change, then either:
> > 
> > a) type in the full name of the desired mailbox,
> > b) type a few characters, then hit  for autocompletion,
> > c) if b) meets multiple alternatives, hit  again, for a list.
> > d) hit , to cycle through visited mailboxes, till you're back.
> 
> e) hit - to go back to the previously visited mailbox

Ah, e) can go back only _one_ mailbox, then goes into an endless back
and forth loop with the last mailbox. That fails entirely to return
further up the history list of previously visited mailboxes. (The
express use-case presented.)

On 26.03.16 15:07, Christian Ebert wrote:
> * Erik Christiansen on Saturday, March 26, 2016 at 23:56:51 +1100
> > On 26.03.16 12:11, Christian Ebert wrote:
> >> * Erik Christiansen on Saturday, March 26, 2016 at 21:52:40 +1100
>
> No, you have to hit 'c' first.
> 
> >>>   "Key is not bound.  Press '?' for help."
> >> 
> >> No, 'c', and then - at the prompt.

Whoops, I read that wrong: "No c". :-(

But now that I can drive "c-", I can only conclude that it serves only
for oscillating between two mailboxes - a use-case which I've not
encountered.

Erik