.H0 "Previous Situation
.P
foo

.H1 "Historic Background
.P
In order to understand the state, goals and dynamics of a project,
you need to know its history. MH comes from a time before the
Internet, a time before networking became universal, a time when
emailing was small, short and simple. Then it grew, spread and
adopted to the changes. The core-concepts, however, remained the
same. During the XXX a small group of students at the University of
California, actively worked on MH. They added features and optimized,
like it is common for scientific work. This is still in pre-ANSI C
times. The source code contains many ancient parts. Code constructs
specific to BSD or hardware of that time are usual.
.P
Nmh started eight years after the ANSI C standard had been
established. A more modern coding style entered the code base. Still
a part of the developers come from ``the old days''. The developer
base became more diverse and thus the code. Programming practices
from different decades merged into the project. Different coding
styles came together. It appears as if multiple peers added code
parts, resulting in a conclomeration rather than an homogenic
of-one-cast mail system. Still, the basic concepts hold it together.
They were mostly untouched throughout the years.
.P
Although, at the surface, nmh is a toolchest, meaning a collection
of completely modularized small programs, on the source code level,
it is much more interweaved. Parts of the basic functions are
collected in a MH standard library, which is good, but often
separate functions are compiled into programs, for effiency reasons.
This lead to intricate innards.
The advent of MIME rose the complexity of email by a magnitude. This
is visible in nmh. The MIME-related parts are the most complex ones.
It's also visible that MIME support had been added on top of the
original MH later. The MH style made this easily possible, but it
also lead to duplicated functions (e.g. \f(CWshow\fP, \f(CWmhshow\fP)
and had not been thoroughly included into the concepts (e.g. the
user-visible access to whole messages and MIME parts are inherently
different).
.P
For compatibility's sake, it is a common understanding to have the
default settings to be compatible, requiring any new feature to be
explicitely enabled. This puts a burden on new users, because nmh
out-of-the-box keeps staying in the same ancient style, where users
usually want to have it practical for modern emailing.
But of course, this depends on if nmh is seen to be a front-end or a
back-end.

.H1 "My Vision
.P
The general goals of the mmh project are the following:
.BU
I believe that mmh should be perfectly suited for modern emailing,
out-of-the-box.
.BU
I care less about compatibility and more about conceptionally elegant
approaches.
.BU
I care for general, clear, and simple concepts.
.BU
I like to create an of-one-style email system.
.BU
I plan to remove any optimizations that rises obscurity, unless it
appears to be neccessary to make mmh usable at all.
.P
.B "The target user in mind
likes Unix and its philosophy.
He likes to use programs that are conceptionally appealing.
He's familiar with the command line and enjoys its power.
He is at least capable of shell scripting and wants to improve his
productivity by scripting the mail system.
His computer and operating system are from post-ANSI C times.
He likes to attach files, exchanges text containing non-ASCII
characters, signs or encrypts his messages.
He does not use bulletin boards anymore, nor non-mbox style mail
drops, nor does he rely on compatibility to nmh.
He already has and MTA/MSA and MRA running or is able to set them
up.
He does not want to have to read a book in order to make his MUA
usable.

.H1 "Things to do
.P