.H0 "Preface" no

.P
I have discovered the mail client \fInmh\fP in September 2009.
At that time I used to use \fImutt\fP, as many advanced Unix users do.
When I read about nmh, its concepts had convinced me at once.
The transition from mutt to nmh was similar to
managing files in the Unix shell when being used to the
\fImidnight commander\fP,
or like editing with vi when being used to modeless editors.
Such a change is not trivial, but in being convinced by the
concepts and by having done similar transitions for file management
and editing already, it was not too difficult.
In contrast, setting up nmh to a convenient state became a tedious task
that took several months.
Once having nmh arranged to a convenient state, I enjoyed using it
because of its conceptional elegance and its scripting capabilities.
On the other hand, nevertheless, it still was
inconvenient for handling attachments, non-ASCII character encodings,
and similar features of modern emailing.
My setup demanded more and more additional configuration and helper scripts
to get nmh behave the way I wanted, although my
expectations were rather common for modern emailing.
In being a computer scientist and programmer,
I wanted to improve the situation.
.P
In Spring 2010, I asked on the \fInmh-workers\fP mailing list for the
possibility to offer a Google Summer of Code project for me.
Participating in the development of nmh this way appeared attractive to me,
because I would have been able to work full time on nmh as the project
could have been part of my official studies at university.
Although the nmh community had been generally positive on the suggestion,
the administrative work for a GSoC project had been to much to have
it realized.
Nontheless, my proposal had activated the nmh community.
In the following weeks, goals for nmh's future were discussed.
In these discussions, I became involved in the
question whether nmh should include mail transfer facilities.
.[
nmh-workers thread mta mua
.]
In this central point, my opinion differed from the opinion of most others.
I argued for the MTA facility of nmh to be removed.
Besides the discussions, hardly any real work was done.
Being unable to work on nmh in a way that would be
accepted as part of my official studies, I needed to choose another project.
.P
Half a year later, starting in August 2010,
I took one semester off to travel through Latin America.
During my time in Argentina, I planned to work on Free Software.
This brought me back to nmh.
Richard Sandelman, an active nmh user, cared for the official basis.
Juan Granda, an argentine Free Software developer,
provided a computer with Internet connection for my work.
Thanks to them, I was able to work on nmh during my three-month
stay in Santiago del Estero in Argentina.
Quickly it became obvious that I wouldn't succeed with my main goal:
improving the character encoding handling within the project.
One of its ramifications is the
missing transfer decoding of quoted text in replies.
As this is one of the most intricate parts of the system, the goal
was simply set too high.
Instead, I improved the code base as I read through it.
I found minor bugs for which I proposed fixes to the community.
In the same go, I improved the documentation in minor ways.
When I started with larger code changes,
I had to discover that the community was reluctant to change.
Its wish for compatibility was much stronger than its
wish for convenient out-of-the-box setups \(en in contrast to my opinion.
This led to long discussions, again.
I came to understand their point of view, but it was different to mine.
At the end of my three-month project, I had become familiar with
nmh's code base and community.
I had improved the project in minor ways,
and I still was convinced that I wanted to go on to do so.
.P
Another half year later, the end of my studies came within reach.
I needed a topic for my master's thesis.
No question, I wanted to work on nmh.
But well, not exactly on nmh, because I had accepted that the
nmh community has different goals than I have.
This would result in much discussion and thus little progress.
After careful thought, I decided to start an experimental version of nmh.
I wanted to implement my own ideas of how an MH-like system should look like.
I wanted to create a usable alternative version to be compared with
the present state of nmh.
Eventually, my work would be proven successful or not.
In any case, the nmh project would profit from my experiences.

.U2 "Focus of this Document
.P
This document explains the design goals and implementation decisions
for mmh.
It discusses technical, historical, social and philosophical considerations.
On the technical side, this document
explains how an existing project was stream-lined by removing rough edges
and exploiting the central concepts better.
On the historical
side, changes through time in the use cases and the email features,
as well as the reactions to them, are discussed.
Socially, this document describes the effects
and experiences of a newcomer with revolutionary aims entering an old
and matured software project.
Philosophical thoughts on style, mainly based to the Unix
philosophy, are present throughout the discussions.
The document describes the changes to nmh,
but as well, it clarifies my personal perception of the
concepts of MH and Unix, and explain my therefrom resulting point of view.
.P
This document is written for the community around MH-like mail systems,
including developers and users.
Despite the focus on MH-like systems, this document is may be precious
to anyone interested in the Unix philosophy and anyone in contact to
old software projects, be it code or community-related.
.P
The reader is expected to be well familiar with Unix, C and emailing.
Good Unix shell knowledge is required, because MH relies fundamentally
on the shell. Without the power of the shell, MH becomes a motorbike
without winding roads: boring.
Introductions to Unix and its shell can be found in ``The UNIX Programming
Environment'' by Kernighan and Pike
.[
kernighan pike unix prog env
.]
or ``The UNIX System'' by Bourne.
.[
bourne unix system
.]
The reader is assumed to be a C programmer,
but the document should be understandable otherwise, too.
The definitive guide to C is Kernighan and Ritchie's
``The C Programming Language''.
.[
kernighan ritchie c prog lang
.]
Some book about system-level C programming can be helpful
additional literature. Rochkind and Curry have written such books.
.[
rochkind advanced unix prog
.]
.[
curry system prog
.]
As large parts of the source code are old,
old books are likely more helpful for understanding.
The reader is expected to know the format of email messages and
the structure of email transfer systems, at least on a basic level.
It's advisable to have cross-read the RFCs 821 and 822.
Further more, basic understanding of MIME is good to have.
The Wikipedia provides good introduction-level information to email.
.P
Frequent references to the Unix philosophy will be made.
Gancarz has tried to sum it up in his book
``The UNIX Philosophy''.
.[
gancarz unix phil
.]
Even better, though less concrete, are ``The UNIX Programming Environment''
.[
kernighan pike unix prog env
.]
and ``The Practice of Programming''
.[
kernighan pike practice of prog
.]
by Kernighan and Pike.
The term paper ``Why the Unix Philosophy still matters''
.[
why unix phil still matters schnalke
.]
by myself
provides an overview on the philosophy, including a case study of MH.
.P
Although a brief introduction to MH is provided in Chapter 1, the reader
is encouraged to have a look at the \fIMH Book\fP
``MH & nmh: Email for Users & Programmers'' by Jerry Peek.
.[
peek mh
.]
The current version is available freely on the Internet.
It is the definitive guide to MH and nmh.
.P
This document is neither a user's tutorial to mmh nor an introduction
to any of the topics covered.
The technical discussions are on an advanced level.
Nevertheless, as knowledge of the fundamental concepts is the most valuable
information a user can acquire about some program or software system,
this document may be worth a read for non-developers as well.


.U2 "Organization
.P
Which font for what use.
Meaning of `foo(1)'.
RFCs.
.P
This thesis is divided into XXX chapters, ...
.P
.I Chapter 1
introduces ...
.P
.I Chapter 2
describes ...
.P
.I Chapter 3
covers ...


.U2 "Acknowledgments
.P
To be written at the very end.