Re: [Nmh-workers] Please proof-read chapter about MH/nmh
[2010-04-12 21:05] Jerrad Pierce
> >Because the man page includes this usage of
> >pick too, but with nmh-1.3, it does not work without -list.
> I have 1.3 and no -list is required here.
> You may have -nolist included in a profile.
No, but I found the reason. The man page to pick(1) says:
`-list' is the default if no `-sequence', `-nolist' otherwise
and my profile includes:
pick: -seq P
> >IMAP and MH do not fit well together, but you can use IMAP in a way,
> >so that MH sees no difference.
> What does grep know of nmh? Or find? Yet you can use them on your mail store.
> Tools in your chest don't have to be specially made to work with another if
> you follow the basic UNIX pilosophy of tool design. Therefore, since nmh
> could get IMAP in this way
I think I see the difference in our views now. I agree with what you
say. Instead of downloading mail with POP, you could use some imapfs
to map the remote mail directory, and leave the mails on the server.
You would want to use this, just because the mail server offers IMAP,
but not NFS/FTP/SSH, which might be better protocols to map a remote
directory (at least from my limited POV).
My view, in contrast, was on the special mail features of IMAP, which
you would loose. (However, there might be few such features.)
> ("just" tweak a package that exposes a Maildir
> interface to offer up MHdir instead), it's another (hypothetical) example.
This is a perfect example here. It's correct that MH would be able to
operate on maildir mailboxes then, but you would loose maildir's main
advantage: guaranteed reliability.
As far as I understand your view now, you think about: How can MH use
a maildir storage without the need to convert it. I think about: How
can MH use maildir's reliability without the need to change MH much.
And similar, tranferred to IMAP.
You see, I agree completely with your opinion on your view of the
problem. But I don't feel that MH does support IMAP. I'd say: MH
needs an MH mail directory in the local file system, and it is
possible to use IMAP (or NFS, or ftpfs, or sshfs) to map a remote mail
directory. But IMO, that's something different.
However, that's nitpicking, or? ;-)
meillo
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Please proof-read chapter about MH/nmh
Thanks for your reply. :-) [2010-04-12 11:20] Jerrad Pierce > 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 ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Please proof-read chapter about MH/nmh
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 One could argue that `mark` is also a filter. 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... 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. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Boomtime, the 29th of Discord, in the YOLD 3176: ...and let me make this perfectly clear I AM NOT superman. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
