Date: Sun, 08 Jan 2006 10:51:56 -0500
From: "Mike O'Dell" <mo@ccr.org>
Message-ID: <43C1351C.20300@ccr.org>
| 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