[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