nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] cleaning out the cobwebs

2010-11-03 13:20:38
[2010-11-03 10:07] Jon Steinhart <jon(_at_)fourwinds(_dot_)com>
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>