as usual, Robert is the voice of rational pragmatism.
nothing done with Yacc will last until the water gets hot -
it looks too closely to tolerate nasty, external reality.
however, i do note the following paper holds out the tantalizing
prospect of efficient *and* (relatively) comprehensible descriptions of
highly, if not rigorously, strutured text objects.
http://arxiv.org/abs/1010.5023
as for MH, i still use MH as my mail repository and *tolerate*
the UW-IMAP server's attempt to use it as well. I do this because
while i read a lot of mail using Thunderbird, no "sealed" mail
UA has the kind of flexibility to find things when you grossly
misfiled them (for instance). in the spirit of "lively discussion",
what about
Do an MH-like plug-in for Tbird/Mozilla/etc ?
all the machinery that's nasty corner cases is there inside Tbird -
what MH provides is a way to orchestrate it in ways other than
the pre-ordained "work flows" built into the code. that might end
up being *more* useful given the somewhat awkward machinations
required to build complex shell-based code with MH.
this would extend the useful life of the MH world-view and expose
it to a lot more people without them having to join
The First Church of the Sanctified Shell Script.
think of it as "schoolyard samples" if nothing else.
-mo
On 12/2/10 3:22 AM, Robert Elz wrote:
Date: Wed, 01 Dec 2010 21:39:37 -0800
From: Jon Steinhart<jon(_at_)fourwinds(_dot_)com>
Message-ID:<201012020539(_dot_)oB25db6v024518(_at_)darkstar(_dot_)fourwinds(_dot_)com>
| A big thing that someone could do to help me with this would be to
| collect all of the various grammar into a single document.
Aside from intellectual curiosity, no, I don't think that's either
needed or useful. We know we can never have everything, as there's
sure to be something new appearing tomorrow - the right solution is
to deal with the general principles properly, not to attempt to be
able to handle every detail (even less so, as half the world's mail
systems generate improperly formed messages, if we think we know what is
correct, half - or more - the mail we ever see will fail).
We need to understand the general principles of header fields, and MIME
separators, etc, and then understand exactly those elements that are
required for the job that is needed - and simply ignore everything else
(leave that for someone who needs it, and can understand and add that
code, or simply ignore it totally if it adds no value for us).
Fortunately the e-mail stuff has evolved in a way that is still highly
compatible even with rfc733, and those that preceded it (let alone 822
and the more recent editions) which allows us to presume that that trend
will continue, and if we take a moderately liberal parsing approach
to deal with what a field looks like, and a very conservative approach
to generation, producing only what should be understood by everyone,
we should get success.
kre
ps: depending upon whether "nmh only" includes exmh or not, I'm also an
nmh only user, I it (with exmh for better mime support...) for all of
my e-mail, and nothing else at all (again, assuming you're willing to
extend nmh to include the rest of the command like tools, like grep, and vi,
and ...)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers