1.1 --- a/ch01.roff	Sat May 19 17:57:20 2012 +0200
     1.2 +++ b/ch01.roff	Sun May 20 11:40:19 2012 +0200
     1.3 @@ -63,7 +63,7 @@
     1.4  
     1.5  .U2 "Concepts
     1.6  .P
     1.7 -MH is a toolchest, modelled after the Unix toolchest. It consists of a
     1.8 +MH is a tool chest, modeled after the Unix tool chest. It consists of a
     1.9  set of tools, each covering a specific task of email handling, like
    1.10  composing a message, replying to a message, refiling a message to a
    1.11  different folder, listing the messages in a folder.
    1.12 @@ -97,14 +97,14 @@
    1.13  adjust them to the user's personal preferences.
    1.14  Multiple versions of the same command with different
    1.15  default values can also be created very easily.
    1.16 -Form templates for new messages or for replies are easily changable,
    1.17 +Form templates for new messages or for replies are easily changeable,
    1.18  and output is adjustable with format files.
    1.19  Almost every part of the system can be adjusted to personal preference.
    1.20  .P
    1.21 -The system is well scriptable and extendable.
    1.22 +The system is well scriptable and extensible.
    1.23  New MH tools are built out of or on top of existing ones quickly.
    1.24 -Further more, MH encourages the user to taylor, extend and automate the system.
    1.25 -As the MH toolchest was modelled after the Unix toolchest, the
    1.26 +Further more, MH encourages the user to tailor, extend and automate the system.
    1.27 +As the MH tool chest was modeled after the Unix tool chest, the
    1.28  properties of the latter apply to the former as well.
    1.29  
    1.30  
    1.31 @@ -164,7 +164,7 @@
    1.32  All this still was in times before POSIX and ANSI C.
    1.33  As large parts of the code stem from this time, today's nmh source code
    1.34  still contains many ancient parts.
    1.35 -BSD-specific code and constructs taylored for hardware of that time
    1.36 +BSD-specific code and constructs tailored for hardware of that time
    1.37  are frequent.
    1.38  .P
    1.39  Nmh started about a decade after the POSIX and ANSI C standards had been
    1.40 @@ -172,16 +172,16 @@
    1.41  a part of the developers came from ``the old days''. The developer
    1.42  base became more diverse and thus resulted in code of different style.
    1.43  Programming practices from different decades merged in the project.
    1.44 -As several peers added code, the system became more a conclomeration
    1.45 -of single tools rather than a homogenic of-one-cast mail system.
    1.46 +As several peers added code, the system became more a conglomeration
    1.47 +of single tools rather than a homogeneous of-one-cast mail system.
    1.48  Still, the existing basic concepts held it together.
    1.49  They were mostly untouched throughout the years.
    1.50  .P
    1.51 -Despite the toolchest approach at the surface \(en a collection
    1.52 +Despite the tool chest approach at the surface \(en a collection
    1.53  of separate small programs \(en on the source code level
    1.54  it is much more interweaved.
    1.55  Several separate components were compiled into one program
    1.56 -for effiency reasons.
    1.57 +for efficiency reasons.
    1.58  This lead to intricate innards.
    1.59  Unfortunately, the clear separation on the outside appeared as being
    1.60  pretty interweaved inside.
    1.61 @@ -189,13 +189,13 @@
    1.62  The advent of MIME rose the complexity of email by a magnitude.
    1.63  This is visible in nmh. The MIME-related parts are the most complex ones.
    1.64  It's also visible that MIME support had been added on top of the old MH core.
    1.65 -MH's toolchest style made this easily possible and encourages
    1.66 +MH's tool chest style made this easily possible and encourages
    1.67  such approaches, but unfortunately, it lead to duplicated functions
    1.68  and half-hearted implementation of the concepts.
    1.69  .P
    1.70  To provide backward-compatibility, it is a common understanding to not
    1.71  change the default settings.
    1.72 -In consequence, the user needs to activate modern features explicitely
    1.73 +In consequence, the user needs to activate modern features explicitly
    1.74  to be able to use them.
    1.75  This puts a burden on new users, because out-of-the-box nmh remains
    1.76  in the same ancient style.
    1.77 @@ -212,10 +212,10 @@
    1.78  when there were no more than three commits to nmh in the previous nine months..
    1.79  In December, when I announced my work on the nmh-workers mailing list,
    1.80  .[
    1.81 -nmh-workers mmh announce december
    1.82 +nmh-workers mmh announce December
    1.83  .]
    1.84  the activity in nmh rose much.
    1.85 -Suddently the community started to move.
    1.86 +Suddenly, the community started to move.
    1.87  This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
    1.88  .[
    1.89  nmh-workers vixie edginess
    1.90 @@ -230,7 +230,7 @@
    1.91  The project follows my personal considerations and preferences.
    1.92  By calling it a personal project, I don't need to justify my decisions,
    1.93  though, still I like to do.
    1.94 -This enabled me to follow my vision staightly and thus produce
    1.95 +This enabled me to follow my vision straightly and thus produce
    1.96  a result of greater pureness.
    1.97  This project model was inspired by the window manager \fIdwm\fP,
    1.98  which is Anselm Garbe's personal window manager \(en
    1.99 @@ -241,7 +241,7 @@
   1.100  This should not happen to mmh.
   1.101  .P
   1.102  Mmh also stands for \fImodern mail handler\fP, and this is
   1.103 -the variant chosen to entitel this document. One main focus of the
   1.104 +the variant chosen to entitle this document. One main focus of the
   1.105  project was to modernize nmh. Another main goal is resembled in the
   1.106  name \fIminimized mail handler\fP: Drop any parts that don't add
   1.107  to the main task of mmh, being a conceptionally appealing MUA.
   1.108 @@ -257,22 +257,22 @@
   1.109  
   1.110  .U2 "Motivation
   1.111  .P
   1.112 -MH is the most important of very few command line toolchest email systems.
   1.113 +MH is the most important of very few command line tool chest email systems.
   1.114  (There's also \fIim\fP by Tatsuya Kinoshita,
   1.115  which operates on an MH mail storage.)
   1.116 -Toolchests are powerful because they can be perfectly automated and
   1.117 -extended. Toolchests are good back-ends for various sorts of front-ends.
   1.118 +Tool chests are powerful because they can be perfectly automated and
   1.119 +extended. Tool chests are good back-ends for various sorts of front-ends.
   1.120  They allow multiple front-ends for different special needs
   1.121 -to be implemented quickly and withough internal knowledge on emailing.
   1.122 -Further more, toolchests are much better to maintain than large monolithic
   1.123 +to be implemented quickly and without internal knowledge on emailing.
   1.124 +Further more, tool chests are much better to maintain than large monolithic
   1.125  programs.
   1.126 -As there are few toolchests for emailing and MH-like ones are the most
   1.127 -popular amoung them, they should be developed further to keep their
   1.128 +As there are few tool chests for emailing and MH-like ones are the most
   1.129 +popular among them, they should be developed further to keep their
   1.130  conceptional elegance and unique scripting qualities available to users.
   1.131  mmh will create a modern and convenient entry point for new, interested
   1.132  users to MH-like systems.
   1.133  .P
   1.134 -The mmh project is motivated by deficites of nmh and
   1.135 +The mmh project is motivated by deficits of nmh and
   1.136  my wish for general changes, combined
   1.137  with the nmh community's reluctancy to change.
   1.138  .P
   1.139 @@ -293,7 +293,7 @@
   1.140  compete with the large specialized projects that focus
   1.141  on only one of the components.
   1.142  The situation can be improved by concentrating the development power
   1.143 -on the most unique part of MH and letting the user pick his prefered
   1.144 +on the most unique part of MH and letting the user pick his preferred
   1.145  set of other mail components.
   1.146  Today's pre-packaged software components encourage this model.
   1.147  mmh is a way to go for this approach.
   1.148 @@ -326,9 +326,9 @@
   1.149  He is at least capable of shell scripting and wants to improve his
   1.150  productivity by scripting the mail system.
   1.151  He naturally uses modern email features, like attachments,
   1.152 -non-ASCII text, and digital cryptrography.
   1.153 +non-ASCII text, and digital cryptography.
   1.154  He is able to setup email system components besides mmh,
   1.155 -and actually likes the choice to pick the ones he preferes.
   1.156 +and actually likes the choice to pick the ones he prefers.
   1.157  He has a reasonably modern system that complies to standards,
   1.158  like POSIX and ANSI C.
   1.159  .P
   1.160 @@ -336,7 +336,7 @@
   1.161  shell session, but as well, he uses them to automate mail handling tasks.
   1.162  Likely, he runs his mail setup on a server machine, to which he connects
   1.163  via ssh. He might also have local mmh installations on his workstations,
   1.164 -but does rather not rely on graphical frontends. He definitely wants
   1.165 +but does rather not rely on graphical front-ends. He definitely wants
   1.166  to be flexible and thus be able to change his setup to suite his needs.
   1.167  .P
   1.168  The typical mmh user is a programmer himself.
   1.169 @@ -385,7 +385,7 @@
   1.170  Time and space optimizations should to be replaced by
   1.171  clear and readable code.
   1.172  A uniform programming style should prevail.
   1.173 -.IP "Homogenity
   1.174 +.IP "Homogeneity
   1.175  The available concepts need to be expanded as far as possible.
   1.176  A small set of concepts should prevail thoroughly throughout the system.
   1.177  The whole system should appear to be of-one-style.