meillo wrote:
Hmm that's then the basic point where we differ. I do care if the
inside is clean and I rather like to remove features than add ones.
From my point of view these are key factors to maintainability and
thus for the future of the code. One of the most important properties
of software is the question if the concepts are most simple and
implemented best possible. If at some time the concepts are found to
be imperfect, I really favor for change.
I admit that providing a drop-in replacement is a fully valid goal. I
rather dislike the fact that this looking back holds us from going
forward. (It's more a general problem, though.)
Then it's time to fork. Especially given that the current code
base has changed surprisingly (to me) little in the last decade
or so. It might not be pretty but it works, at least well
enough to get used often.
While maintenance is painful, that doesn't happen very often.
And the intricate dependencies of people and frontends on nmh
restrict the kinds of changes that can reasonably be made. For
example, while I don't use many, or even most, of nmh's
features, I think it would be a really bad idea to remove any of
them.
I could see an argument for starting over from scratch, but it's
clear that not enough people have enough spare time for that.
Another data point: I use nmh exclusively as my MUA.
Also, I haven't used mhbuild (mime at the whatnow prompt) since
I started using -attach. It's very easy to use and it certainly
does work well.
David
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers