> 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@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Reply via email to