Jon Steinhart wrote:
Any attempt to rewrite or replace it ought to be preceded by the buildup
of the kind of test suite mentioned in the comments in m_getfld.c and
subsequently (alas) lost to history. (Some of the code in test/tests/inc
is trying to make a start on that.) But if you just want to make nmh's
handling of MIME or attachments better or improve its UI, you don't need
to spend time doing anything with m_getfld anyway.
This made sense to me until the last sentence. The particular changes that I
want to make involve parsing the mime stuff inside of the 822 style message
bodies. I suppose that you could argue that I should make a new function
that
would parse the bodies. Maybe that's the way to go.
Yes. m_getfld will give you the body text (in a series of chunks
the size of the buffer you hand it, IIRC) and what you do with
it after that is up to you. This is how nmh's existing MIME
handling code works. (I suppose you could propose replacing
m_getfld completely with something with a different and MIME
aware API, but that would be an extensive project...)
-- PMM
Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld call
something that sort of looks like m_getfld but is different. Making it work
down
to all of the body parts would in my mind be architecturally better for nmh.
But,
as you say, more work.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers