Jon Steinhart <jon(_at_)fourwinds(_dot_)com> 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 <*> epg(_at_)pretzelnet(_dot_)org
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