Re: [Nmh-workers] cleaning out the cobwebs

[Jon Steinhart]

> While reading much nmh code these days, I also feel that parts of the
> code are ancient. I'd like to support any effort in renewing it.
> 
> Autoconf is something I dislike.

I suppose that I'm willing to do some work here too if I'm not alone.  My main
interest, which I expressed years ago, is to figure out what sbr/m_getfld.c is
really doing and rewrite it so that I can add additional functionality without
breaking anything.

The functionality that I want to add is better handling of attachments.  Even
though there have been some complaints long after the fact, I think that my
code that simplified sending attachments was a success.  But, it's my opinion
that receiving attachments still needs work.  Here's what I had, and still have
in mind...

I can currently get a scan like this (names removed):

5901  10/28 XXXXXXXXX XXXXXXX  Re: Coming down your way soon<<Boob cancer. Prog
5904  10/28 XXXXXXX XXXXXX     FW: Hallowe'en2010<<--_000_1D0D56EB54ECF6428182E
5906  10/29 XXXXXXXXX XXXXXXX  Re: Coming down your way soon<<Thanks. I am doin
5907+ 10/29 XXXXXXX XXXXXXXXX  Election editorial cartoons<<--Apple-Mail-19-856
5908  10/30 "XXXXX XX XXXXXX"  Re: 2010 bring a friend<<On Sat, Oct 30, 2010 at

The problem for me is the current message, 5907 (and 5904 which I'll skip for 
now):

% mhlist
 msg part  type/subtype              size description                         
5907       multipart/alternative     334K
     1     multipart/related         333K
     1.1   text/html                 3840
     1.2   image/gif                 8961
     1.3   image/jpg                  41K
     1.4   image/jpg                  61K
     1.5   image/jpg                  55K
     1.6   image/gif                  75K
     2     text/plain                 357

This is painful and useless.  And I really don't like what happens when I show a
message with a lot of attachments and they keep on popping up even though I want
to move on to the next message.  I'd like an option to scan that would give me
something like this:

5901    10/28 XXXXXXXXX XXXXXXX  Re: Coming down your way soon<<Boob cancer. 
Prog
5904    10/28 XXXXXXX XXXXXX     FW: 
Hallowe'en2010<<--_000_1D0D56EB54ECF6428182E
5906    10/29 XXXXXXXXX XXXXXXX  Re: Coming down your way soon<<Thanks. I am 
doin
5907+   10/29 XXXXXXX XXXXXXXXX  Election editorial 
cartoons<<--Apple-Mail-19-856
 .1           text/html          I decided to stick to just one topic, since the
 .1.2         image/gif          JGPfwdtoon.gif
 .1.3         image/jpg          Lukovich - election 2010.jpg
 .1.4         image/jpg          Kirk GOP no solutions-1.jpg
 .1.5         image/jpg          Luckovich - Money - Republicans - Obama.jpg
 .1.6         image/gif          toles - Public voted out.gif
 .2           text/plain         I decided to stick to just one topic, since the
5908    10/30 "XXXXX XX XXXXXX"  Re: 2010 bring a friend<<On Sat, Oct 30, 2010 
at

I'd then like the ability to do something like

        show 5907.1.2

or maybe if 5907 is the current message just the ability to do something like

        show .1.2

Then, I'd like the ability to do something like

        next -part

and
        prev -part

These would show the next/previous part of a message, moving to the next or 
previous
message when the parts run out.  In other words, I'd like a consistent 
interface for
dealing with messages and their parts.

Let me know what you think.  I don't want this to be like the attachment 
sending code
where nobody had anything to say until a few years after it was done and then 
started
complaining.

Again, the stumbling block here is m_getfld.c and my not wanting Van Jacobson, 
his
children, and my children cursing me as per the comments.

Separate from the above, I would like to see as much as the pre-Posix gratuitous
stuff removed from sbr.  It's fine with me if going forward, new versions of nmh
only run on Posix-compatible systems.  I too am a hater of autoconf/automake;  I
like elegance, not the ugliest sledgehammer in existence.  That said, I'd rather
use these than create new ones.

In my mind, the best way to start a clean-up project is for people to go into 
the
existing code and add good comments.  As with m_getfld.c, the big stumbling 
block
is not understanding what the stuff that's already there does.  Once it's 
understood
it's probably pretty easy to change.

BTW, it seems to me that part of what's going on in m_getfld.c is poking around 
in
stdio buffers to avoid fetching the data twice.  Most message are pretty small 
so
I've wondered whether it would be better to just memory map the files.  Or, 
maybe
systems are fast enough today that we can just bail on the tricky stuff and use
stdio.  Any opinions?

That's all for now.

        Jon