If we're having lazy evaluation of MIME parts, which is good, can it
also cover the headers? `pick --list-id <foo(_at_)bar(_dot_)com>' isn't
concerned
with decoding Subject and all those Received headers. It may not sound
like much, but we have folders with tens of thousands of emails.
get_header() could note minimal details of each header it comes across
whilst searching for the List-ID but not bother too much about their
contents.
I wasn't actually thinking of decoding the headers for things like MIME
content, at least upon read (I assume you're talking about RFC 2047
encoding; personally I doubt you'd notice it on a modern machine, but
I understand where you're coming from). I was thinking of using an
accessor function to take care of that.
Also, http://www.ietf.org/rfc/rfc2919.txt says only one List-ID per
email; does nmh have knowledge of one-off headers so it can stop
reading headers on the first match? That pick uses the `--' as pick
doesn't know of List-ID, unlike, say, Subject; perhaps it needs to know
of more official headers so it can make use of one-off-ness.
Nmh does _not_ know about those things; I'm sort of torn about that.
Right now most tools will combine headers like that into one super-long
header, but the handling is not uniform. Seems like maybe things like
that should be handled by the accessor function; we can give you the
choice of combining headers, or getting first match. Something to think
about!
Whilst looking at pick's source, I found MHPDEBUG; I don't think it's
documented but could be useful for those learning pick? Perhaps it
should be -debug instead?
I'm with David on this; yes, it should be -debug and documented.
Also-also, access to raw and decoded headers would be nice, e.g. I
sometimes want to find Subjects that have `=?utf-8?' in them.
Okay, I guess I could see that. The normal case would be to decode the
contents completely
That's the kind of overhead that would be nice to see done only on
demand.
I'm still skeptical that you'd even notice (it isn't 1988 anymore!),
but I think if the API was well designed it should be easy to implement.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers