Re: [Nmh-workers] cleaning out the cobwebs

[markus schnalke]

[2010-11-03 10:07] Jon Steinhart <address@hidden>
> > 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.

Great! I'm at your side. :-)

About my time: I have free time until Christmas, which I put into the
quoted reply thing, as already announced. Then I'll travel again and
will be offline until April. From April until summer I like to work on
nmh again, besides my studies.


> 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.

How performance optimizations haunt you after so many years ...


> 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.

The current attachment approach collides with running `mime' on the
whatnow prompt. But this is only one other problem originating in the
approach that was taken to implement MIME support.


> 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 to have show(1)/mhshow(1) redesigned. The programs should be
merged when MIME support is not something sitting on top anymore. IMO
show(1) should per default display:
- for non-MIME: the whole message
- for MIME: the first text/plain part and the output of mhlist(1)


> 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, in contrast, would like to have scan(1) only work on message
headers and not deal with any body data. This could ease things as
more clear separations (which tools deal with files, headers, body
(=MIME)) could be made.


> 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

I agree.

Currently MIME support is just put upon MH. IMO we should fully
integrate MIME into nmh. This would remove several ugly (nonintuitive)
parts.


> Then, I'd like the ability to do something like
> 
>       next -part

Here I'm not so sure. Because we would have three states then: folder,
msg, and part. But I'm not decided on this yet.


> 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.

I don't want to blame Van Jacobson, as this might had been a very
valuable improvement back then. The point is simply that the
optimization drove m_getfld.c into a dead end for further development.
Perhaps it's best to start with the code before he optimized it and
track the changes since.


> 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 think a lot about all this these days. The difficulty is always the
compatibility.


> 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.

Many alternative approaches have their problems too. I like best how
it is done by the suckless project [0] and the heirloom tools [1].
This involves a bit of manual configuration but saves a lot of
complexity therewith.

[0] http://suckless.org
[1] http://heirloom.sf.net


> 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.

In the view of usability for developers, I'd like to see nmh switching
from the centralistic CVS to some distributed version control system.
This would ease trying stuff and exchanging patches. But that's a
different discussion.


meillo