Re: [Nmh-workers] (n)mh tip of the day

[Bob Carragher]

On Wed, 21 Oct 2015 05:56:54 +0700 Robert Elz <address@hidden> sez:

>     Date:        Tue, 20 Oct 2015 14:33:19 -0700
>     From:        Bob Carragher <address@hidden>
>     Message-ID:  <address@hidden>
> 
>   | I don't manage multiple mailboxes,
> 
> I do.
> 
>   | but I sometimes change my "real name" in the header.
> 
> But I almost never want to do that.   But ...
> 
>   | For that, I've set up a bunch of commands that are basically
>   |      repl -form <form-with-different-real-name>
> 
> I do it that way as well, except ...
> 
>   | That requires that I have a message to reply to,
> 
> I do the same for comp & forw (with components files, and
> forwcomps files).  I never bothered to set this up for "dist" -
> in general, what's in the Resent-From: matters not in the
> slightest to anything...
> 
> From a usability point of view, whether using an alias (or sh
> function, which is more common for me), or setting MH_FROM in
> the env, really makes no difference.  My (our) way does mean
> that there are multiple *comps files to edit whenever a

Same for me.

> systematic change is required, which can be a nuisance, but it

Fortunately, systematic changes have been rare (for me).

> also means that it is trivial to change more than just the
> From:, eg:  when I send from hostmaster@ I almost always want a
> Fcc: to a particular folder inserted, so the *comps files for
> it can have the Fcc ready in it.  (and more similar).  For
> replcomps files, the way I generate the To: and Cc: addresses
> varies (slightly) based upon which file I'm using (even when
> the From: doesn't alter.)

This is a key feature, and something I didn't mention.  Different
replies may be archived in different folders (so, varying Fcc:s),
I usually want to just reply to the mailing list and not Cc the
poster of the message I'm replying to (so, To:, Cc:, and Bcc: are
hard-coded in these).

> On odd occasions, *comps files can be generated on the fly for
> one off use.
>
> Part of what's great about MH is that we get to combine the
> shell (and all its tools) with the mh commands, to handle
> whatever out own needs happen to be, and aren't restricted to
> just what the MUA authors decided would be sufficient
> facilities.

And so there are many different ways to get the job done!

                                Bob