1.1 --- a/ch01.roff	Thu Jun 21 08:58:56 2012 +0200
     1.2 +++ b/ch01.roff	Sat Jun 23 22:08:17 2012 +0200
     1.3 @@ -10,7 +10,7 @@
     1.4  .P
     1.5  This chapter introduces MH, its history, concepts and how it is used.
     1.6  It describes nmh's code base and community to give the reader
     1.7 -a better understanding of the state from which mmh started off.
     1.8 +a better understanding of the state of mmh when it started off.
     1.9  Further more, this chapter outlines the mmh project itself,
    1.10  describing the motivation for it and its goals.
    1.11  
    1.12 @@ -29,19 +29,19 @@
    1.13  .U2 "History
    1.14  .P
    1.15  In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
    1.16 -had proposed the design
    1.17 +proposed the design
    1.18  of a new mail handling system, called ``Mail Handler'' (MH),
    1.19  to superseed RAND's old monolithic ``Mail System'' (MS).
    1.20  Two years later, in 1979, Bruce Borden took the proposal and implemented a
    1.21  prototype of MH.
    1.22 -Before the prototype had been available, the concept was
    1.23 +Before the prototype's existence, the concept was
    1.24  believed to be practically unusable.
    1.25 -But the prototype had proven successful and replaced MS thereafter.
    1.26 +But the prototype proved successful and replaced MS thereafter.
    1.27  In replacing MS, MH grew to an all-in-one mail system.
    1.28  .P
    1.29 -In the early Eighties,
    1.30 -the University of California at Irvine (UCI) had started to use MH.
    1.31 -Marshall T. Rose and John L. Romine became the driving force then.
    1.32 +In the early eighties,
    1.33 +the University of California at Irvine (UCI) started to use MH.
    1.34 +Marshall T. Rose and John L. Romine then became the driving force.
    1.35  They took over the development and pushed MH forward.
    1.36  RAND had put the code into the public domain by then.
    1.37  MH was developed at UCI at the time when the Internet appeared,
    1.38 @@ -51,7 +51,7 @@
    1.39  RFCs. In the advent of MIME, MH was the first implementation of this new
    1.40  email standard.
    1.41  .P
    1.42 -In the Nineties, the Internet had become popular and in December 1996,
    1.43 +In the nineties, the Internet had become popular and in December 1996,
    1.44  Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
    1.45  Nmh is a fork of MH 6.8.3 and bases strongly on the
    1.46  \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
    1.47 @@ -64,7 +64,7 @@
    1.48  Some systems might still provide old MH, but mainly for historical reasons.
    1.49  .P
    1.50  In the last years, the work on nmh was mostly maintenance work.
    1.51 -However, the development revived in December 2011
    1.52 +However, development was revived in December 2011
    1.53  and stayed busy since then.
    1.54  
    1.55  .U2 "Concepts
    1.56 @@ -76,23 +76,23 @@
    1.57  .P
    1.58  The mail storage consists of \fImail folders\fP (directories) and
    1.59  \fPmessages\fP (regular files).
    1.60 -Each message is stored in a separate file in the format it had been
    1.61 +Each message is stored in a separate file in the format it was
    1.62  received (i.e. transfer format).
    1.63  The files are named with ascending numbers in each folder.
    1.64  The specific format of the mail storage characterizes MH in the same way
    1.65 -like the format of the file system characterizes Unix.
    1.66 +as the format of the file system characterizes Unix.
    1.67  .P
    1.68  MH tools maintain a \fIcontext\fP, which includes the current mail folder.
    1.69  Processes in Unix have a similar context, containing the current working
    1.70  directory, for instance. In contrast, the process context is maintained
    1.71  by the Unix kernel automatically, whereas MH tools need to maintain the MH
    1.72  context themselves.
    1.73 -The user can have one MH context or multiple ones, he can even share it
    1.74 -with other users.
    1.75 +The user can have one MH context or multiple ones; he can even share it
    1.76 +with others.
    1.77  .P
    1.78  Messages are named by their numeric filename, but they can have symbolic names,
    1.79  too. These are either automatically updated
    1.80 -position names like being the next or the last message,
    1.81 +position names such as the next or the last message,
    1.82  or user-settable group names for arbitrary sets of messages.
    1.83  These names are called sequences.
    1.84  Sequences can be bound to the containing folder or to the context.
    1.85 @@ -148,7 +148,7 @@
    1.86  .U2 "Using MH
    1.87  .P
    1.88  It is strongly recommended to have a look at the MH Book,
    1.89 -which introduces well into using MH.
    1.90 +which offers a thorough introduction to using MH.
    1.91  .[ [
    1.92  peek mh book
    1.93  .], Part II]
    1.94 @@ -160,7 +160,7 @@
    1.95  .P
    1.96  Following is an example mail handling session.
    1.97  It uses mmh but is mostly compatible with nmh and old MH.
    1.98 -Details might vary but the look'n'feel is the same.
    1.99 +Details might vary but the look and feel is the same.
   1.100  
   1.101  .VF input/mh-session
   1.102  
   1.103 @@ -168,14 +168,14 @@
   1.104  .H1 "nmh: Code and Community
   1.105  .P
   1.106  In order to understand the condition, goals and dynamics of a project,
   1.107 -one needs to know the reasons.
   1.108 +one needs to know the reasons behind them.
   1.109  This section explains the background.
   1.110  .P
   1.111 -MH predates the Internet, it comes from times before networking was universal,
   1.112 +MH predates the Internet; it comes from times before networking was universal,
   1.113  it comes from times when emailing was small, short and simple.
   1.114 -Then it grew, spread and adopted to the changes email went through.
   1.115 +Then it grew, spread and adapted to the changes email went through.
   1.116  Its core-concepts, however, remained the same.
   1.117 -During the Eighties students at UCI actively worked on MH.
   1.118 +During the eighties, students at UCI actively worked on MH.
   1.119  They added new features and optimized the code for the then popular systems.
   1.120  All this still was in times before POSIX and ANSI C.
   1.121  As large parts of the code stem from this time, today's nmh source code
   1.122 @@ -183,30 +183,34 @@
   1.123  BSD-specific code and constructs tailored for hardware of that time
   1.124  are frequent.
   1.125  .P
   1.126 -Nmh started about a decade after the POSIX and ANSI C standards had been
   1.127 +Nmh started about a decade after the POSIX and ANSI C standards were
   1.128  established. A more modern coding style entered the code base, but still
   1.129  a part of the developers came from ``the old days''. The developer
   1.130 -base became more diverse and thus resulted in code of different style.
   1.131 +base became more diverse, thus broadening the range of different
   1.132 +coding styles.
   1.133  Programming practices from different decades merged in the project.
   1.134  As several peers added code, the system became more a conglomeration
   1.135  of single tools rather than a homogeneous of-one-cast mail system.
   1.136  Still, the existing basic concepts held it together.
   1.137  They were mostly untouched throughout the years.
   1.138  .P
   1.139 -Despite the tool chest approach at the surface \(en a collection
   1.140 -of separate small programs \(en on the source code level
   1.141 -it is much more interweaved.
   1.142 +Despite the separation of the tool chest approach at the surface
   1.143 +\(en a collection of small, separate programs \(en
   1.144 +on the source code level, it is much more interweaved.
   1.145  Several separate components were compiled into one program
   1.146  for efficiency reasons.
   1.147 -This lead to intricate innards.
   1.148 -Unfortunately, the clear separation on the outside appeared as being
   1.149 -pretty interweaved inside.
   1.150 +This led to intricate innards.
   1.151 +While clearly separated on the outside,
   1.152 +the programs turned out to be fairly interweaved inside.
   1.153 +.\" XXX FIXME rewrite...
   1.154 +.\" Unfortunately, the clear separation on the outside turned out to be
   1.155 +.\" fairly interweaved inside.
   1.156  .P
   1.157 -The advent of MIME rose the complexity of email by a magnitude.
   1.158 +The advent of MIME raised the complexity of email by a magnitude.
   1.159  This is visible in nmh. The MIME-related parts are the most complex ones.
   1.160 -It's also visible that MIME support had been added on top of the old MH core.
   1.161 +It is also visible that MIME support was added on top of the old MH core.
   1.162  MH's tool chest style made this easily possible and encourages
   1.163 -such approaches, but unfortunately, it lead to duplicated functions
   1.164 +such approaches, but unfortunately, it led to duplicated functions
   1.165  and half-hearted implementation of the concepts.
   1.166  .P
   1.167  To provide backward-compatibility, it is a common understanding to not
   1.168 @@ -216,16 +220,16 @@
   1.169  This puts a burden on new users, because out-of-the-box nmh remains
   1.170  in the same ancient style.
   1.171  If nmh is seen to be a back-end, then this compatibility surely is important.
   1.172 -However, in the same go, new users have difficulties to use nmh for modern
   1.173 +However, in the same go, new users have difficulties using nmh for modern
   1.174  emailing.
   1.175 -The small but matured community around nmh hardly needs much change
   1.176 -as they have their convenient setups since decades.
   1.177 +The small but mature community around nmh needs few change
   1.178 +as they have had their convenient setups for decades.
   1.179  
   1.180  
   1.181  .H1 "mmh
   1.182  .P
   1.183  I started to work on my experimental version in October 2011,
   1.184 -at a time when there were no more than three commits to nmh
   1.185 +at a time when there had been no more than three commits to nmh
   1.186  since the beginning of the year.
   1.187  In December, when I announced my work in progress on the
   1.188  nmh-workers mailing list,
   1.189 @@ -238,8 +242,8 @@
   1.190  nmh-workers vixie edginess
   1.191  .]
   1.192  After long years of stagnation, nmh became actively developed again.
   1.193 -Hence, while I was working on mmh, the community was working on nmh,
   1.194 -in parallel.
   1.195 +Hence, while I was working on mmh, the community was once more working
   1.196 +on nmh, in parallel.
   1.197  .P
   1.198  The name \fImmh\fP may stand for \fImodern mail handler\fP,
   1.199  because the project tries to modernize nmh.
   1.200 @@ -260,31 +264,31 @@
   1.201  Tool chests are powerful because they can be perfectly automated and
   1.202  extended. They allow arbitrary kinds of front-ends to be
   1.203  implemented on top of them quickly and without internal knowledge.
   1.204 -Additionally, tool chests are much better to maintain than monolithic
   1.205 +Additionally, tool chests are easier to maintain than monolithic
   1.206  programs.
   1.207  As there are few tool chests for emailing and as MH-like ones are the most
   1.208 -popular among them they should be developed further.
   1.209 +popular among them, they should be developed further.
   1.210  This keeps their
   1.211  conceptional elegance and unique scripting qualities available to users.
   1.212 -Mmh will create a modern and convenient entry point to MH-like systems
   1.213 +Mmh creates a modern and convenient entry point to MH-like systems
   1.214  for new and interested users.
   1.215  .P
   1.216  The mmh project is motivated by deficits of nmh and
   1.217  my wish for general changes, combined
   1.218  with the nmh community's reluctancy to change.
   1.219  .P
   1.220 -nmh hadn't adjusted to modern emailing needs well enough.
   1.221 +At that time, nmh had not adjusted to modern emailing needs well enough.
   1.222  The default setup was completely unusable for modern emailing.
   1.223  Too much setup work was required.
   1.224  Several modern features were already available but the community
   1.225 -didn't wanted to have them as default.
   1.226 -mmh is a way to change this.
   1.227 +did not want to have them as default.
   1.228 +Mmh is a way to change this.
   1.229  .P
   1.230  In my eyes, MH's concepts could be exploited even better and
   1.231  the style of the tools could be improved. Both would simplify
   1.232  and generalize the system, providing cleaner interfaces and more
   1.233  software leverage at the same time.
   1.234 -mmh is a way to demonstrate this.
   1.235 +Mmh is a way to demonstrate this.
   1.236  .P
   1.237  In providing several parts of an email system, nmh can hardly
   1.238  compete with the large specialized projects that focus
   1.239 @@ -293,18 +297,18 @@
   1.240  on the most unique part of MH and letting the user pick his preferred
   1.241  set of other mail components.
   1.242  Today's pre-packaged software components encourage this model.
   1.243 -mmh is a way to go for this approach.
   1.244 +Mmh is a way to go for this approach.
   1.245  .P
   1.246 -It's worthwhile to fork nmh for the development of mmh, because
   1.247 +It is worthwhile to fork nmh for the development of mmh, because
   1.248  the two projects focus on different goals and differ in fundamental questions.
   1.249 -The nmh community's reluctance to change conflicts
   1.250 -with my strong will to change.
   1.251 +The nmh community's reluctance regarding change conflicts
   1.252 +with my strong desire for it.
   1.253  In developing a separate experimental version new approaches can
   1.254  easily be tried out without the need to discuss changes beforehand.
   1.255  In fact, revolutionary changes are hardly possible otherwise.
   1.256  .P
   1.257 -The mmh project provides the basis to implemented and demonstrated
   1.258 -the listed ideas without the need to change nmh or its community.
   1.259 +The mmh project implements and demonstrates the listed ideas
   1.260 +without the need to change nmh or its community.
   1.261  Of course, the results of the mmh project shall improve nmh, in the end.
   1.262  
   1.263  .U2 "Target Field

     2.1 --- a/preface.roff	Thu Jun 21 08:58:56 2012 +0200
     2.2 +++ b/preface.roff	Sat Jun 23 22:08:17 2012 +0200
     2.3 @@ -15,22 +15,20 @@
     2.4  that took several months.
     2.5  Once having nmh arranged to a convenient state, I enjoyed using it
     2.6  because of its conceptional elegance and its scripting capabilities.
     2.7 -Nevertheless, it still was inconvenient for handling attachments,
     2.8 +Nevertheless, it was still inconvenient for handling attachments,
     2.9  non-ASCII character encodings, and similar features of modern emailing.
    2.10  My setup demanded more and more additional configuration and helper scripts
    2.11  to have nmh behave the way I wanted; yet my
    2.12  expectations were rather common for modern emailing.
    2.13 -In being a computer scientist and programmer,
    2.14 -I wanted to improve the situation.
    2.15 +As a computer scientist and programmer, I wanted to improve the situation.
    2.16  .P
    2.17 -In Spring 2010, I asked on the \fInmh-workers\fP mailing list for the
    2.18 -possibility to offer a Google Summer of Code project for me.
    2.19 -Participating in the development of nmh this way appeared attractive to me,
    2.20 -because I would have been able to work full time on nmh.
    2.21 -Although the nmh community had been generally positive on the suggestion,
    2.22 -the administrative work for a GSoC project had been to much to have
    2.23 -it realized.
    2.24 -Nontheless, my proposal had activated the nmh community.
    2.25 +In Spring 2010, I sent a message to the \fInmh-workers\fP mailing list,
    2.26 +asking for the possibility to offer a Google Summer of Code project for me.
    2.27 +Participating in the development of nmh in this manner appeared attractive
    2.28 +to me, because I would have been able to work full time on nmh.
    2.29 +Although the nmh community had reacted generally positive to the suggestion,
    2.30 +the administrative work for a GSoC project would had been too much.
    2.31 +Nonetheless, my proposal had activated the nmh community.
    2.32  In the following weeks, goals for nmh's future were discussed.
    2.33  In these discussions, I became involved in the
    2.34  question whether nmh should include mail transfer facilities.
    2.35 @@ -49,11 +47,11 @@
    2.36  During my time in Argentina, I wanted to work on Free Software.
    2.37  This brought me back to nmh.
    2.38  Richard Sandelman, an active nmh user, cared for the official basis.
    2.39 -Juan Granda, an argentine Free Software developer,
    2.40 +Juan Granda, an Argentine Free Software developer,
    2.41  provided a computer with Internet connection.
    2.42  Thanks to them, I was able to work on nmh during my three-month
    2.43  stay in Santiago del Estero, Argentina.
    2.44 -Quickly it became obvious that I wouldn't succeed with my main goal,
    2.45 +Quickly it became obvious that I would not succeed with my main goal,
    2.46  to improve the character encoding handling.
    2.47  (One of its ramifications is the
    2.48  missing transfer decoding of quoted text in replies.)
    2.49 @@ -66,7 +64,7 @@
    2.50  I had to discover that the community was reluctant to change.
    2.51  Its wish for compatibility was much stronger than its
    2.52  wish for convenient out-of-the-box setups \(en in contrast to my opinion.
    2.53 -This led to long discussions, again.
    2.54 +This, once again, led to long discussions.
    2.55  I came to understand their point of view, but it was different to mine.
    2.56  At the end of my three-month project, I had become familiar with
    2.57  nmh's code base and community,
    2.58 @@ -75,9 +73,9 @@
    2.59  .P
    2.60  Another half year later, the end of my studies came within reach.
    2.61  I needed a topic for my master's thesis.
    2.62 -No question, I wanted to work on nmh.
    2.63 -But well, not exactly on nmh, because I had accepted that the
    2.64 -nmh community has different goals than I have.
    2.65 +Without question, I wanted to work on nmh.
    2.66 +But not exactly on nmh, because I had accepted that its
    2.67 +community has different goals than I have.
    2.68  Working on nmh would result in much discussion and, in consequence,
    2.69  little progress.
    2.70  After careful thought, I decided to start an experimental version of nmh.
    2.71 @@ -94,14 +92,14 @@
    2.72  It discusses technical, historical, social and philosophical considerations.
    2.73  On the technical side, this document
    2.74  explains how an existing project was stream-lined by removing rough edges
    2.75 -and exploiting the central concepts better.
    2.76 -On the historical
    2.77 -side, changes through time in the use cases and the email features,
    2.78 -as well as the reactions to them, are discussed.
    2.79 +and better exploitation of the central concepts.
    2.80 +On the historical side, changes through time are discussed,
    2.81 +regarding the use cases and the email features,
    2.82 +as well as the reactions to them.
    2.83  Socially, this document describes the effects
    2.84  and experiences of a newcomer with revolutionary aims entering an old
    2.85  and matured software project.
    2.86 -Philosophical thoughts on style, mainly based to the Unix
    2.87 +Philosophical thoughts on style, mainly based on the Unix
    2.88  philosophy, are present throughout the discussions.
    2.89  The document describes the changes to nmh,
    2.90  but as well, it clarifies my personal perception of the
    2.91 @@ -109,11 +107,11 @@
    2.92  .P
    2.93  This document is written for the community around MH-like mail systems,
    2.94  including developers and users.
    2.95 -Despite the focus on MH-like systems, this document is may be precious
    2.96 -to anyone interested in the Unix philosophy and anyone in contact to
    2.97 -old software projects, be it code or community-related.
    2.98 +Despite the focus on MH-like systems, this document may be valuable
    2.99 +to anyone interested in the Unix philosophy and anyone in contact with
   2.100 +old software projects, be it code- or community-related.
   2.101  .P
   2.102 -The reader is expected to be well familiar with Unix, C and emailing.
   2.103 +The reader is expected to be familiar with Unix, C and emailing.
   2.104  Good Unix shell knowledge is required, because MH relies fundamentally
   2.105  on the shell. Without the power of the shell, MH becomes a motorbike
   2.106  without winding roads: boring.
   2.107 @@ -133,21 +131,21 @@
   2.108  .[
   2.109  kernighan ritchie c prog lang
   2.110  .]
   2.111 -Some book about system-level C programming can be helpful
   2.112 -additional literature. Rochkind and Curry have written such books.
   2.113 +A book about system-level C programming can be helpful
   2.114 +additional literature, such as those written by Rochkind and Curry.
   2.115  .[
   2.116  rochkind advanced unix prog
   2.117  .]
   2.118  .[
   2.119  curry system prog
   2.120  .]
   2.121 -As large parts of the source code are old,
   2.122 -old books are likely more helpful for understanding.
   2.123 +Old books are likely more helpful for understanding,
   2.124 +because large parts of the source code are old.
   2.125  The reader is expected to know the format of email messages and
   2.126  the structure of email transfer systems, at least on a basic level.
   2.127  It's advisable to have cross-read the RFCs 821 and 822.
   2.128  Further more, basic understanding of MIME is good to have.
   2.129 -The Wikipedia provides good introduction-level information to email.
   2.130 +The Wikipedia provides good introduction-level information about email.
   2.131  .P
   2.132  Frequent references to the Unix philosophy will be made.
   2.133  Gancarz has tried to sum it up in his book