[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Please proof-read chapter about MH/nmh
From: |
markus schnalke |
Subject: |
Re: [Nmh-workers] Please proof-read chapter about MH/nmh |
Date: |
Mon, 12 Apr 2010 22:39:36 +0200 |
User-agent: |
nmh 1.3 |
Thanks for your reply. :-)
[2010-04-12 11:20] Jerrad Pierce <address@hidden>
> Section 4.4 Re: filters
>
> `pick` is a mail-aware grep-like filter
> I use it in a chain-like way via:
> alias pscan 'scan `pick !:*`' #tcsh
I needed the -list option to make pick print message numbers. Did the
default change for this? Because the man page includes this usage of
pick too, but with nmh-1.3, it does not work without -list.
However, thanks for pointing this out, it's a good example. I think
I'll add this.
> Section 4.5 Re: IMAP
> You should probably revisit the list discussion and include some of the
> points?
> For instance, most of those who spoke up seem to support falling back on the
> Unix Way and farming out IMAP support to some other tool, be that a FUSE layer
> or something else. Some IMAP features would not be readily available, but the
> general mailstore would be, at no cost to us...
I know about this approach and generally support it, but what is the
difference to ftpfs, sshfs, or NFS then? With this approach, IMAP
would just map a remote directory into the local directory tree.
I don't know much about IMAP, but Wikipedia lists ``server-side
searches'' for instance. This would not be possible. Do you understand
my point? If IMAP would just map a directory, then it has nothing to
do with MH. Any other FUSE layer would be equally good.
IMAP and MH do not fit well together, but you can use IMAP in a way,
so that MH sees no difference.
> Re: habits
>
> exmh is not pretty, but mh-e has its followers, and is no worse (and indeed
> better for not tying up a terminal, just a buffer) than elm/pine/mutt.
Thanks for the information. Unfortunately, for many people you're
already a geek when you use elm/pine/mutt. ;-)
meillo