--- a/ch01.roff	Wed May 16 20:42:30 2012 +0200
+++ b/ch01.roff	Thu May 17 16:17:09 2012 +0200
@@ -233,8 +233,6 @@
 After long years of much stagnation, nmh became actively developed again.
 Hence, while I was working on mmh, the community was working on nmh,
 in parallel.
-
-.U2 Naming
 .P
 The name \fImmh\fP stands for \fImeillo's mail handler\fP,
 because mmh is my own version of MH.
@@ -264,33 +262,11 @@
 However, this step backward actually is a step forward,
 although in another direction.
 
+
+.H1 "This Thesis
+
 .U2 "Motivation
 .P
-The mmh project is motivated by deficites of nmh and
-my wish for general changes, combined
-with the nmh community's reluctancy to change.
-.P
-nmh hadn't adjusted to modern emailing needs well enough.
-The default setup was completely unusable for modern emailing.
-Too much setup work was required.
-Several modern features were already available but the community
-didn't wanted to have them as default.
-.P
-In my eyes, the concepts could be exploited even better and
-the style of the tools could be improved. Both would would simplify
-and generalize the system, providing cleaner interfaces and more
-software leverage, at the same time.
-.P
-In providing several parts of an email system, nmh would hardly
-be able to compete with the large specialized projects that focus
-on only one of the components. Concentrating all development power
-on the most unique part of nmh and giving the user the choice to
-pick his prefered set of the other mail components would be the better
-approach in my eyes.
-Today's pre-packaged software components encourage this approach.
-
-.U2 "Why it is worth it
-.P
 MH is the most important of very few command line toolchest email systems.
 (There's also \fIim\fP by Tatsuya Kinoshita,
 which operates on an MH mail storage.)
@@ -306,6 +282,32 @@
 mmh will create a modern and convenient entry point for new, interested
 users to MH-like systems.
 .P
+The mmh project is motivated by deficites of nmh and
+my wish for general changes, combined
+with the nmh community's reluctancy to change.
+.P
+nmh hadn't adjusted to modern emailing needs well enough.
+The default setup was completely unusable for modern emailing.
+Too much setup work was required.
+Several modern features were already available but the community
+didn't wanted to have them as default.
+mmh is a way to change this.
+.P
+In my eyes, MH's concepts could be exploited even better and
+the style of the tools could be improved. Both would simplify
+and generalize the system, providing cleaner interfaces and more
+software leverage, at the same time.
+mmh is a way to demonstrate this.
+.P
+In providing several parts of an email system, nmh can hardly
+compete with the large specialized projects that focus
+on only one of the components.
+The situation can be improved by concentrating the development power
+on the most unique part of MH and letting the user pick his prefered
+set of other mail components.
+Today's pre-packaged software components encourage this model.
+mmh is a way to go for this approach.
+.P
 It's worthwhile to fork nmh for the development of mmh, because
 the two projects focus on different goals and differ in fundamental questions.
 The nmh community's reluctance to change conflicts
@@ -313,15 +315,19 @@
 In developing a separate experimental version new approaches can
 easily be tried out without the need to discuss changes beforehand.
 In fact, revolutionary changes are hardly possible otherwise.
-By forking nmh, mmh will likelier bring fresh air into the field of
-MH-like mail systems than without forking.
-Fresh air is good to reactivate a matured project.
+These reasons support the decision to start mmh as a fork of nmh.
 .P
-These reasons support the decision to start mmh as a fork of nmh.
+The mmh project provides the basis to implemented and demonstrated
+the listed ideas without the need to change nmh or its community.
 Of course, the results of the mmh project shall improve nmh, in the end.
 
 .U2 "Target Field
 .P
+Any effort needs to be targeted towards a specific goal
+in order to be successful.
+Following is a description of the imagined typical mmh user.
+mmh should satisfy his needs.
+.P
 The target user of mmh 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.
@@ -335,26 +341,28 @@
 like POSIX and ANSI C.
 .P
 XXX common scenarios?
-
-.U2 "The Vision
 .P
-The general goals of the mmh project are the following:
+General assumptions of the project are:
 .BU
-I believe that mmh should be perfectly suited for modern emailing,
-out-of-the-box.
+Elegance \(en being simplicity, clarity and generality \(en is most important.
 .BU
-I care less about compatibility and more about conceptionally elegant
-approaches.
-.BU
-I care for general, clear, and simple concepts.
+Concepts are more important than concrete implementations.
 .BU
-I like to create an of-one-style email system. It should feel like
-cast as one.
+Time and space optimizations are only useful if absolutely needed to make
+the software usable.
 .BU
-I plan to remove any optimizations that rises obscurity, unless it
-appears to be neccessary to make mmh usable at all.
+Having a lot of choice is bad.
 
 .U2 "Work to do
+.P
+The general goals for the mmh project are the following:
+.BU
+mmh should be perfectly suited for modern emailing, out-of-the-box.
+This is a necessity to spread among new users.
+.BU
+The system shall be of-one-style. It should feel like cast as one.
+.P
+To do list:
 .BU
 Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
 task. Mail shall enter mmh's mail storage via the system mail drop
@@ -380,11 +388,6 @@
 .BU
 Provide a ready-to-use setup out-of-the-box.
 
-
-.H1 "Goals of this Thesis
-
 .U2 "Methods
 .P
 foo
-mmh wants to provide a ready-to-use setup for modern emailing,
-which is a necessity to spread among new users.