> Jon Steinhart <[EMAIL PROTECTED]> writes: > > > Also, I didn't mean to start a flame war with my questions > > about the code. It's my opinion that nmh has about twice as > > much code as is really needed to do the job. That excess > > fluff makes the code harder to understand and maintain. So > > I'm gonna trim it out whenever I see it. Not to show off, > > but to make the code easier to deal with. > > If you want something to do as far as duplication reduction goes, > check out mhbuildsbr.c and mhparse.c. Have a barf bag handy. > > -- > Eric Gillespie <*> [EMAIL PROTECTED]
Funny. My main reason for looking at stuff is because I want to add features, and right now there's nothing that I want to do there. The changes that I made to handle sending attachments at least keep the user from having to see that stuff. See doc/README-ATTACHMENTS in the CVS if you don't know about this. My interest in m_getfld is because I'd like to experiment with the way that attachments are shown. It'd be interesting to get a bit of discussion on this. Basically, I don't like the way that message parts are treated differently than messages. To me, there's little difference between receiving a message with two attachments and three messages. I'd like to see an indented scan that shows something like 5785+ 11/19 Eric Gillespie Re: The continuing install-mh saga<<Jon Steinhar .1 <image/jpeg> .2 <image/jpeg> ant then be able to do show/next/prev on stuff. I find it really annoying to have all body parts displayed in a single batch, especially those that involve some interaction to get rid of, like closing an image viewer. Jon
