Date: Sun, 08 Jan 2006 10:51:56 -0500 From: "Mike O'Dell" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]>
| MH already has a rich model for "folders", and that | should be respected deeply - it is the principal attraction of MH! I am going to (slightly) disagree with that - not suggesting in any way that the folder model isn't important, but disagreeing that this is the principal attraction of MH. To me, what MH is all about, and the reason I use MH, rather than something rather more "modern", is the relationship between the "MH" commands, and the rest of the shell and all the other available commands. That is, if you believe that MH is defined by what comes from the nmh-1.2.tar.gz file (or whatever it is called) then most probably, you shouldn't be using MH at all - one of the other integrated MUA's that is available these days is probably going to do all you want, and better, than this (limited) MH can possibly offer. To make full use of MH, you have to use it, together with all the rest of the power of the shell - and I don't just mean "show | lpr" or similar. We get offered glimpses from time to time of Jerry Peek's extensive collection of MH add-ons - that is the kind of thing that makes MH worth using. Rather than have you all go back and find one (or more) or Jerry's offerings, let me show you a couple I use ... The first is a shell function - go back far enough in time and this one was a csh alias (or more accurately, a much more primitive version of this was a csh alias) - it could just as easily be a script, but ... vim () { local A B M; B=; M=; for A in "$@"; do case "$A" in -*) B="${B} '${A}'" ;; +*) B="${B} '${A}'" ;; *) M="${M} '${A}'" ;; esac; done; test -z "${M}" && M=cur; eval set -$- X $B $M; shift; vi `mhpath "$@"` } (excuse the slightly ugly format, I got that from the "type" command in the shell, rather than going and finding the file in which it is defined). That allows me to edit a message (or messages) (vi message - hence vim - a name I have been using for this from way before the vi kind-of-clone known by the same name ever existed). Not too much in that, but very useful. Another ... #! /bin/sh SPAM=spam case "$1" in --reload|--rebuild|--sync) exec sa-learn --sync exit 0 ;; --spam) SPAM=spam; shift ;; --ham) SPAM=ham; shift ;; esac case "$#-$1" in 1-+*) set -- "$1" unseen ;; esac FILES= for name in `mhpath "$@"` do if [ -d "$name" ]; then sa-learn --no-sync --$SPAM --dir $name else FILES="${FILES} $name" ## sa-learn --no-sync --$SPAM --file $name fi done test -n "$FILES" && sa-learn --no-sync --$SPAM --file $FILES This one (I call it "spam" for fairly obvious reasons) integrates the spamassassin learning command into MH. Typically I read all of my mail, skipping the spam that spamassassin didn't catch, and then do spam unseen +folder rmm unseen +folder (so often this, that, as you will see above, "unseen" is the default arg to "spam" just as "cur" is to many MH command - and yes, if I care about doing this properly, I'd be using mh-param rather than just assuming that "Unseen-Sequence: unseen" exists in the MH profile (this is just for me, and I know that it is there...) I have lots more, as should (usually) any other MH user - it is this kind of thing that makes MH worth using, and which leaves all the other monotonic MUAs way behind. Usually (and in my case certainly, including the two shown above) these little add-ons are very personal, doing things that are of no use to anyone but their author (I have "mass reply" commands, that take a whole (particular) folder of messages and send a canned reply to every message, and all kinds of other junk like that). That is, there's very little to be gained by distributing most of this stuff. The relevance of this to the current dicsussion, is that unless the plan to integrate IMAP means "treat an IMAP server like a POP server" (that is: fetch mail from where the MTA stored it and move it into the MH folder structure), which would be an OK (and easy) thing to do, then you aren't finished until you have the IMAP part of your MH folders just as accessible to all of these add-on shell commands as to the (much smaller) set of commands that are distributed in nmh-whatever.tgz. The suggestion to make an IMAP filesystem (as linux centric as the original suggestion was) is clearly the direction that would allow MH and IMAP to work together properly. Embedding IMAP knowledge into show, next, scan, pick, refile, ... just fails to meet almost any useful objective. If you accept that however, the next thing to accept is that an IMAP filesystem and MH have nothing to do with each other really - that is, someone doing an IMAP filesystem need not be aware of MH really at all, it is something that MH could use, if implemented, but which there's no particular reason for the MH community to be involved in implementing. kre _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers