Stephen Eglen | 6 Jun 04:50 2008
Picon
Picon

Switching from VM to mh-e

Hi,

After using RMAIL for 3 years and VM for about 11 years, I've now
decided its time to switch mailer again.  (VM is starting to show a few
issues with CVS Emacs, and I would prefer a mailer that came bundled
with GNU Emacs...)  I've spent the last week or so trying GNUS for
reading email, but have not yet found it to be what I'm looking for,
and after reading most of the info for mh-e, think it might suit my
needs.  I thought I'd ask a few questions though before diving in:

1. I do like the VM/RMAIL way of keeping mail in mbox format, and am not
sure yet if I'll "like" the switch to the onefile per message format.
In particular, I'm concerned about how it might interfere with my
backup/syncing process.  (I keep my desktop and laptop in sync using
"unison".)  I saw a recent thread on the nmh mailing list noting this as
a concern, and wondered if anyone here had anything to say -- do the
file names change often?  (I'm not sure what the "folder pack" operation
is -- is it renaming of files so that they are in a contiguous
sequence?)  Does mh-e often rename files within a message folder?

http://lists.gnu.org/archive/html/nmh-workers/2008-05/msg00043.html

2. I have many years worth of files in mbox format -- I probably won't
convert most of them, but is there anyway of converting between mbox
and mh format?  (Both ways, in case I decide I don't stick with mh-e?)
I guess Gnus might help here, as it can read both types.

3. I didn't see any mention of parsing ~/.aliases in the manual -- is it
not used?  (I use mailabbrev.el for dynamically expanding aliases, and
assume that could fit into mh-e somehow... I know enough elisp and, like
(Continue reading)

Mike Kupfer | 6 Jun 05:50 2008
Picon

Re: Switching from VM to mh-e

I use the filesync program in Solaris to synchronize work email with
multiple laptops.  It works well enough but only if I use MH-E in a
stylized manner.  More on that below.  I suspect you could get the same
results with Unison.

>>>>> "SJE" == Stephen Eglen <S.J.Eglen <at> damtp.cam.ac.uk> writes:

SJE> (I keep my desktop and laptop in sync using "unison".)  I saw a
SJE> recent thread on the nmh mailing list noting this as a concern, and
SJE> wondered if anyone here had anything to say -- do the file names
SJE> change often?

File names will change if you pack or sort a folder.  That's a manual
operation, though you'll want to avoid nightly cron jobs that pretty up
your folders for you.

If you use procmail(1) or slocal(1) to deliver your mail, you also need
to consider conflicts where you move a message into folder foo on the
laptop, and your desktop delivers new mail into folder foo.  On the
other hand, if you get new mail by manually running inc(1), this
shouldn't be a problem (assuming you resync before getting new mail).

SJE> (I'm not sure what the "folder pack" operation is -- is it renaming
SJE> of files so that they are in a contiguous sequence?)

Yes.

SJE> Does mh-e often rename files within a message folder?

AFAIK only if you tell it to.
(Continue reading)

Bill Wohler | 6 Jun 07:40 2008
Picon
Picon

Re: Switching from VM to mh-e

Mike answered most of your questions. I've added what I can.

Stephen Eglen <S.J.Eglen <at> damtp.cam.ac.uk> wrote:

> 1. I do like the VM/RMAIL way of keeping mail in mbox format, and am not
> sure yet if I'll "like" the switch to the onefile per message format.

Once you get used to it, you'll hate the one file per folder format. The
MH way is so much more conducive to shell scripts and Unix aficionados,
and file system corruption tends to affect fewer messages.

> 2. I have many years worth of files in mbox format -- I probably won't
> convert most of them, but is there anyway of converting between mbox
> and mh format?

To add to what Mike said:

for mbox in *.mbox; do
    inc -file $mbox +$mbox
done

See the inc man page for details.

> 3. I didn't see any mention of parsing ~/.aliases in the manual -- is it
> not used?  (I use mailabbrev.el for dynamically expanding aliases, and
> assume that could fit into mh-e somehow... I know enough elisp and, like
> Jim Laurus, found elisp more fun than dissertation writing, which ended
> up in iswitchb.el...).

As Mike mentioned, MH has its own aliases format. MH-E has a capability
(Continue reading)

Stephen Eglen | 6 Jun 21:33 2008
Picon
Picon

Re: Switching from VM to mh-e

Dear Bill, Mike, thanks for your quick responses to my queries.  I've
now started trialling mh-e, and will hopefully follow up with further
ideas/questions later.

Best wishes, Stephen

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Stephen Eglen | 9 Jun 13:46 2008
Picon
Picon

Re: Switching from VM to mh-e


Following up on my email last week, I've started trying out mh-e, and
find it quite nice.  One thing that immediately struck me was the way
mh-e displays header information: it seems to show all the header except
for what has been made invisible by regexps like
mh-invisible-header-fields-default.  These regexps seem quite extensive,
but will never be enough to satisy everyone (e.g. here locally we have
extra headers added for the spam filter, along the lines of :

  X-Cam-SpamDetails: Not scanned
  X-Cam-AntiVirus: No virus found
  X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/

My guess is that the regexps for hiding header fields are always
changing... By contrast, both VM and GNUS hide most of the header and
only show a limited number of headers by default, typically:

  From: To: CC: Subject: Date:   (see below for exact list)

This means that the start of the message in VM and GNUS is nearly always
easy to predict, typically around line 5, and my eye is easily drawn to
it.  With mh-e, depending on the number of headers displayed, the
message could start anywhere.  This forces me to read the headers which
normally I don't want to do (and can always display the raw message if i
want to examine them.)

Is there way to get more GNUS/VM like behaviour?  e.g. would it be worth
implementing something along the lines of vm's vm-visible-headers (see
below)?

(Continue reading)

Stephen Eglen | 9 Jun 17:30 2008
Picon
Picon

Re: Switching from VM to mh-e


Following up on my earlier message:

> Is there way to get more GNUS/VM like behaviour?  e.g. would it be worth
> implementing something along the lines of vm's vm-visible-headers (see
> below)?

Reading the mh-e archives  I see that this behaviour used to exist in
mh-e, and that mh-visible-header-fields did exist but was deleted,
e.g. see previous message:

  From: Eric Jensen <jensen <at> hven.astro.swarthmore.edu>
  Subject: Re: Three questions
  Newsgroups: gmane.mail.mh-e.user
  To: mh-e-users <at> lists.sourceforge.net
  Date: Mon, 05 Feb 2007 17:30:22 -0500

Any chance of accepting a patch to reinstate mh-visible-header-fields,
and perhaps using it only if mh-invisible-header-fields-default is nil
(or some such option)?

Stephen

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Peter Galbraith | 9 Jun 18:45 2008
Picon

Re: Switching from VM to mh-e

Stephen Eglen <S.J.Eglen <at> damtp.cam.ac.uk> wrote:

> 
> Following up on my email last week, I've started trying out mh-e, and
> find it quite nice.  One thing that immediately struck me was the way
> mh-e displays header information: it seems to show all the header except
> for what has been made invisible by regexps like
> mh-invisible-header-fields-default.  These regexps seem quite extensive,
> but will never be enough to satisy everyone (e.g. here locally we have
> extra headers added for the spam filter, along the lines of :
> 
>   X-Cam-SpamDetails: Not scanned
>   X-Cam-AntiVirus: No virus found
>   X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/

We are constantly adding more.  Simply report the ones you feel would be
hidden, or add them to your own system:

M-x customize-variable [RET] mh-invisible-header-fields [RET]

> My guess is that the regexps for hiding header fields are always
> changing... By contrast, both VM and GNUS hide most of the header and
> only show a limited number of headers by default, typically:
> 
>   From: To: CC: Subject: Date:   (see below for exact list)

MH-E used to have that too (the old 'visible' variable, counterpart to
mh-invisible-header-fields).  I guess we decided that is was safer to
decide what to NOT know than to be sure (forever) of what to only show.

(Continue reading)

Peter Galbraith | 9 Jun 19:11 2008
Picon

Re: Switching from VM to mh-e

Stephen Eglen <S.J.Eglen <at> damtp.cam.ac.uk> wrote:

> 
> 
> Following up on my earlier message:
> 
> > Is there way to get more GNUS/VM like behaviour?  e.g. would it be worth
> > implementing something along the lines of vm's vm-visible-headers (see
> > below)?
> 
> Reading the mh-e archives  I see that this behaviour used to exist in
> mh-e, and that mh-visible-header-fields did exist but was deleted,

Right. I did that on July 28th 2003:

mh-customize.el (mh-invisible-header-fields-internal): Renamed
from prior `mh-invisible-header-fields-default'.
(mh-invisible-header-fields-default): Renamed from prior
`mh-invisible-header-fields-default-override'.
(mh-invisible-header-fields): Renamed from prior
`mh-invisible-header-fields-user'.
(mh-visible-headers): Removed!  We use invisible fields only now.
(mh-visible-header-fields): Removed!

Yes, it would be possible to add it back.  But firstly, let me
respectfully request that you try adding your mh-invisible-header-fields
for a while to see if you can't get used to that.  You might find that
you prefer it.  If we add it back, we'll need to have it customizable so
that people can add to the list of what they see.

(Continue reading)

Stephen Eglen | 9 Jun 19:52 2008
Picon
Picon

Re: Switching from VM to mh-e

Dear Peter,

Thanks for your responses.  I probably could get used to the mh-e
behavior, but as I think it is at odds with other mailers, I'd rather
just see the typical headers that I'm used to seeing.

> mh-customize.el (mh-invisible-header-fields-internal): Renamed
> from prior `mh-invisible-header-fields-default'.
> (mh-invisible-header-fields-default): Renamed from prior
> `mh-invisible-header-fields-default-override'.
> (mh-invisible-header-fields): Renamed from prior
> `mh-invisible-header-fields-user'.
> (mh-visible-headers): Removed!  We use invisible fields only now.
> (mh-visible-header-fields): Removed!

Thanks, this would give me a starting point to look at.

> Earlier you said you had to read the header to find the beginning of a
> message.  Simply look for the second paragraph (after the first empty
> line).

yes, I agree, but that is much harder to do when the number of header
lines varies from message to message so drastically.

Thanks, stephen

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
(Continue reading)

Jeffrey C Honig | 9 Jun 19:56 2008
Picon

Re: Switching from VM to mh-e

Do we still have the option to use the external MH program to format a
message?  Then you can configure that they way you like.

Thanks (谢谢).

Jeff

Stephen Eglen <S.J.Eglen <at> damtp.cam.ac.uk> wrote:

> Dear Peter,
> 
> Thanks for your responses.  I probably could get used to the mh-e
> behavior, but as I think it is at odds with other mailers, I'd rather
> just see the typical headers that I'm used to seeing.
> 
> > mh-customize.el (mh-invisible-header-fields-internal): Renamed
> > from prior `mh-invisible-header-fields-default'.
> > (mh-invisible-header-fields-default): Renamed from prior
> > `mh-invisible-header-fields-default-override'.
> > (mh-invisible-header-fields): Renamed from prior
> > `mh-invisible-header-fields-user'.
> > (mh-visible-headers): Removed!  We use invisible fields only now.
> > (mh-visible-header-fields): Removed!
> 
> Thanks, this would give me a starting point to look at.
> 
> 
> > Earlier you said you had to read the header to find the beginning of a
> > message.  Simply look for the second paragraph (after the first empty
> > line).
(Continue reading)


Gmane