nmh-workers
[Top] [All Lists]

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

2015-10-20 20:25:32
On Wed, 21 Oct 2015 05:56:54 +0700 Robert Elz 
<kre(_at_)munnari(_dot_)oz(_dot_)au> sez:

    Date:        Tue, 20 Oct 2015 14:33:19 -0700
    From:        Bob Carragher <dnc2dnc(_at_)gmail(_dot_)com>
    Message-ID:  
<5626b320(_dot_)4816430a(_dot_)b973e(_dot_)fffff935(_at_)mx(_dot_)google(_dot_)com>

  | 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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>