1.1 --- a/intro.roff	Thu Jul 12 20:01:46 2012 +0200
     1.2 +++ b/intro.roff	Thu Jul 12 22:04:51 2012 +0200
     1.3 @@ -20,7 +20,7 @@
     1.4  .Id mh
     1.5  .P
     1.6  MH is a conceptual email system design and its concrete implementation.
     1.7 -Notably, MH had started as a design proposal at RAND Corporation,
     1.8 +MH had started as a design proposal at RAND Corporation,
     1.9  where the first implementation followed later.
    1.10  In spirit, MH is similar to Unix, which
    1.11  influenced the world more in being a set of system design concepts
    1.12 @@ -39,13 +39,13 @@
    1.13  shapiro gaines mh proposal
    1.14  .]
    1.15  to superseed RAND's old monolithic \fIMail System\fP (MS).
    1.16 -More than one year later, in late 1978, Bruce Borden returned to the
    1.17 +One year later, in 1978, Bruce Borden picked up on the
    1.18  proposal and implemented a prototype, which he called
    1.19  \fIMail Handler\fP (MH).
    1.20  Before the prototype's existence, the concept was
    1.21  believed to be practically unusable.
    1.22  But the prototype \(en written in only three weeks \(en
    1.23 -proved successful and replaced MS within six months.\&
    1.24 +proved successful and replaced MS thereafter.\&
    1.25  .[ [
    1.26  rand note design of mh
    1.27  .], p. 4]
    1.28 @@ -58,32 +58,31 @@
    1.29  rand note design of mh
    1.30  .], p. 4]
    1.31  RAND had put the code into the public domain by then.
    1.32 -MH was developed at UCI at the time when the Internet appeared,
    1.33 -the BSD started to include TCP/IP networking,
    1.34 +MH was developed at UCI at the same time when the Internet appeared,
    1.35 +BSD started to support TCP/IP networking,
    1.36  and Eric Allman wrote Sendmail.
    1.37  MH was extended as emailing became more featured.
    1.38  The development of MH was closely related to the development of email RFCs.
    1.39  In the advent of the \fIMultipurpose Internet Mail Extensions\fP (MIME),
    1.40  MH was one of the first implementations of the new email standard.
    1.41 -MH grew to provide anything necessary for emailing.
    1.42  .P
    1.43  In the nineties, the Internet became popular and in December 1996,
    1.44  Richard Coleman initiated the \fINew Mail Handler\fP (nmh) project.
    1.45 -Nmh is a fork of MH 6.8.3 and bases strongly on the
    1.46 +Nmh is a fork of MH 6.8.3 and bases heavily on the
    1.47  \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
    1.48  .[
    1.49  lbl changes
    1.50  .]
    1.51  Colman intended to modernize MH and improve its portability and
    1.52  MIME handling capabilities.
    1.53 -This should be done openly within the Internet community.
    1.54  The development of MH at UCI stopped after the 6.8.4 release in
    1.55  February 1996, soon after the development of nmh had started.
    1.56 -Today, nmh has almost completely replaced the original MH.
    1.57 -Some systems might still provide old MH, but mainly for historical reasons.
    1.58 +Today, nmh is developed openly in the Internet community.
    1.59 +It has almost completely replaced the original MH.
    1.60 +Some systems might still provide the old MH, but hardly for good reasons.
    1.61  .P
    1.62 -In the last years, the changes in nmh were mostly maintenance work.
    1.63 -However, the development was revived in December 2011
    1.64 +In the last years, the majority of changes in nmh was maintenance work.
    1.65 +Nevertheless, the development was revived in December 2011
    1.66  and stayed busy since then.
    1.67  
    1.68  
    1.69 @@ -140,34 +139,11 @@
    1.70  with different default values.
    1.71  Form templates for new messages and replies, as well as format files
    1.72  to adjust the output of tools are easily exchanged in the profile.
    1.73 +Almost every part of the system can be adjusted to personal preference.
    1.74  .P
    1.75 -Switches consist of a single dash (`\fL-\fP') followed by a word.
    1.76 -To ease typing, the word can be abbreviated, given the remaining
    1.77 -prefix remains unambiguous.
    1.78 -If no other switch starts with the letter `t', then any of
    1.79 -.Cl "-truncate" ,
    1.80 -.Cl "-trunc" ,
    1.81 -.Cl "-tr" ,
    1.82 -and
    1.83 -.Cl "-t
    1.84 -is equal.
    1.85 -As a result, switches can neither be grouped (as in
    1.86 -.Cl "ls -ltr" )
    1.87 -nor can switch arguments be appended directly to the switch (as in
    1.88 -.Cl "sendmail -q30m" ).
    1.89 -Many switches have negating counter-parts, which start with `no'.
    1.90 -For example
    1.91 -.Cl "-notruncate
    1.92 -inverts the
    1.93 -.Cl "-truncate
    1.94 -switch.
    1.95 -They exist to override the effect of default switches in the profile.
    1.96 -.P
    1.97 -The system is well scriptable and extensible.
    1.98 -Almost every part of the system can be adjusted to personal preference.
    1.99 +The whole system is well scriptable and extensible.
   1.100  New MH tools are built out of or on top of existing ones quickly.
   1.101 -Furthermore, MH encourages the user to tailor, extend, and automate
   1.102 -the system.
   1.103 +MH encourages the user to tailor, extend, and automate the system.
   1.104  As the MH tool chest was modeled after the Unix tool chest, the
   1.105  properties of the latter apply to the former as well.
   1.106  
   1.107 @@ -185,22 +161,22 @@
   1.108  .[
   1.109  hegardt mh for beginners
   1.110  .]
   1.111 -are old, but they still teach the basics.
   1.112 -Rose and Romine introduce MH deeper and more technical in two dozen pages.
   1.113 +are old, but still they teach the concepts and basics,
   1.114 +which remained unchanged.
   1.115 +Rose and Romine have written an excellent introduction on a more
   1.116 +technical level, with pointers to advanced usage.
   1.117  .[
   1.118  rose romine real work
   1.119  .]
   1.120 -For a more recent introduction, it is strongly recommended to have
   1.121 -a look at the \fIMH Book\fP.
   1.122 +For a more recent document, it is strongly recommended to have
   1.123 +a look at the \fIMH Book\fP,
   1.124  .[ [
   1.125  peek mh book
   1.126  .], Part II]
   1.127 -The online version of the book was updated on in May 2006.
   1.128 +especially at its online version.
   1.129  .P
   1.130 -Following here is an example mail handling session.
   1.131 -Although it uses mmh, it is mostly compatible with nmh and the
   1.132 -original MH.
   1.133 -Details might vary but the look and feel is the same.
   1.134 +Following here is a sample mail handling session with mmh.
   1.135 +Details might vary to MH and nmh but the look and feel is the same.
   1.136  
   1.137  .so input/mh-session
   1.138  
   1.139 @@ -209,66 +185,59 @@
   1.140  .P
   1.141  In order to understand the condition, goals and dynamics of a project,
   1.142  one needs to know the reasons behind them.
   1.143 -This section explains the background.
   1.144 +This section gives background information.
   1.145  .P
   1.146  MH predates the Internet;
   1.147 -it comes from times before networking was universal,
   1.148 +it comes from times before networking was universal;
   1.149  it comes from times when emailing was small, short and simple.
   1.150 -Then it grew, spread and adapted to the changes email went through.
   1.151 -Its core-concepts, however, remained the same.
   1.152 +Then, MH grew, spread and adapted to the changes email went through.
   1.153 +Its core concepts, however, remained the same.
   1.154  During the eighties, students at UCI actively worked on MH.
   1.155  They added new features and optimized the code for the systems
   1.156  popular at that time.
   1.157 -All this still was in times before POSIX and ANSI C.
   1.158 +This was in times before POSIX and ANSI C.
   1.159  As large parts of the code stem from this time, today's nmh source code
   1.160  still contains many ancient parts.
   1.161  BSD-specific code and constructs tailored for hardware of that time
   1.162  are frequent.
   1.163  .P
   1.164 -Nmh started about a decade after the POSIX and ANSI C standards were
   1.165 -established. A more modern coding style entered the code base, but still
   1.166 -a part of the developers came from ``the old days''. The developer
   1.167 -base became more diverse, thus broadening the range of different
   1.168 -coding styles.
   1.169 +Nmh started about one decade after the POSIX and ANSI C standards were
   1.170 +released.
   1.171 +A more modern coding style entered the code base but still
   1.172 +a part of the developers were ``of the old type''.
   1.173 +The developer base became more diverse,
   1.174 +thus broadening the range of different coding styles.
   1.175  Programming practices from different decades merged in the project.
   1.176  As several peers added code, the system became more a conglomeration
   1.177  of single tools rather than a homogeneous of-one-cast mail system.
   1.178 -Still, the existing basic concepts held it together.
   1.179 +For that, leadership would have been necessary.
   1.180 +Nevertheless, MH's basic concepts held the project together.
   1.181  They were mostly untouched throughout the years.
   1.182  .P
   1.183 -Despite the separation of the tool chest approach at the surface
   1.184 -\(en a collection of small, separate programs \(en
   1.185 -on the source code level, it is much more interwoven.
   1.186 -Several separate components were compiled into one program
   1.187 +Though clearly separated on the surface
   1.188 +\(en as a collection of small, separate programs \(en
   1.189 +the source code turns out to be fairly interwoven.
   1.190 +Multiple separate components are compiled into a program
   1.191  for efficiency reasons.
   1.192 -This led to intricate innards.
   1.193 -While clearly separated on the outside,
   1.194 -the programs turned out to be fairly interwoven inside.
   1.195 -.\" XXX FIXME rewrite...
   1.196 -.\" nicht zweimal ``interwoven''
   1.197 -.\" Unfortunately, the clear separation on the outside turned out to be
   1.198 -.\" fairly interwoven inside.
   1.199 +This leads to intricate innards.
   1.200  .P
   1.201 -The advent of MIME raised the complexity of email by a magnitude.
   1.202 -This is visible in nmh. The MIME-related parts are the most complex ones.
   1.203 +It is visible in nmh that
   1.204 +the advent of MIME raised the complexity of email by a magnitude.
   1.205 +The MIME-related parts are the most complex ones.
   1.206  It is also visible that MIME support was added on top of the old MH core.
   1.207  MH's tool chest style made this easily possible and encourages
   1.208  such approaches, but unfortunately, it led to duplicated functions
   1.209 -and half-hearted implementation of the concepts.
   1.210 +and half-hearted implementation of concepts.
   1.211  .P
   1.212 -To provide backward-compatibility, it is a common understanding not to
   1.213 -change the default settings.
   1.214 -In consequence, the user needs to activate modern features explicitly
   1.215 +To provide backward-compatibility, it is a common understanding
   1.216 +in the nmh community to not change the default settings.
   1.217 +In consequence, users need to activate modern features explicitly
   1.218  to be able to use them.
   1.219 -This puts a burden on new users, because out-of-the-box nmh remains
   1.220 -in the same ancient style.
   1.221 -If nmh is seen to be a back-end,
   1.222 -then this compatibility surely is important.
   1.223 -However, at the same time, new users have difficulties using nmh for
   1.224 -modern emailing.
   1.225 -The small but mature community around nmh needs little change
   1.226 +The ancient style in which fresh nmh setups remain to appear
   1.227 +causes difficulties for new users, as modern email features require
   1.228 +additional configuration.
   1.229 +The small but mature community around nmh, however, needs little change
   1.230  as they have had their convenient setups for decades.
   1.231 -.\" XXX Explain more
   1.232  
   1.233  
   1.234  .H1 "mmh
   1.235 @@ -276,9 +245,9 @@
   1.236  I started to work on my experimental version in October 2011,
   1.237  basing my work on nmh version \fInmh-1.3-dev\fP.
   1.238  At that time no more than three commits were made to nmh
   1.239 -since the beginning of the year, the latest one being
   1.240 -.Ci a01a41d031c796b526329a4170eb23f0ac93b949
   1.241 -on 2011-04-13.
   1.242 +since the beginning of 2011, the latest one being
   1.243 +.Ci a01a41d031c796b526329a4170eb23f0ac93b949 ,
   1.244 +commited on 2011-04-13.
   1.245  In December, when I announced my work in progress on the
   1.246  nmh-workers mailing list,
   1.247  .[
   1.248 @@ -291,7 +260,7 @@
   1.249  .]
   1.250  After long years of stagnation, nmh became actively developed again.
   1.251  Hence, while I was working on mmh, the community was working on nmh,
   1.252 -in parallel.
   1.253 +in parallel but unrelated.
   1.254  .P
   1.255  The name \fImmh\fP may stand for \fImodern mail handler\fP,
   1.256  because the project tries to modernize nmh.
   1.257 @@ -305,7 +274,7 @@
   1.258  .]
   1.259  which is Anselm Garbe's personal window manager \(en
   1.260  targeted to satisfy Garbe's personal needs whenever conflicts appear.
   1.261 -Dwm had retained its lean elegance and its focused character, whereas
   1.262 +Dwm has retained its lean elegance and its focused character, whereas
   1.263  its community-driven predecessor \fIwmii\fP
   1.264  .[
   1.265  wmii website
   1.266 @@ -318,42 +287,40 @@
   1.267  .P
   1.268  MH is the most important of very few email systems in a tool chest style.
   1.269  Tool chests are powerful because they can be perfectly automated and
   1.270 -extended. They allow arbitrary kinds of front-ends to be
   1.271 -implemented on top of them quickly and without internal knowledge.
   1.272 +extended.
   1.273 +They allow the implementation of arbitrary kinds of front-ends
   1.274 +on top of the tool chest quickly and without internal knowledge.
   1.275  Additionally, tool chests are easier to maintain than monolithic
   1.276  programs.
   1.277 -As there are few tool chests for emailing and as MH-like ones are the most
   1.278 -popular among them, they should be developed further.
   1.279 -This keeps their
   1.280 -conceptional elegance and unique scripting qualities available to users.
   1.281 -Mmh creates a modern and convenient entry point to MH-like systems
   1.282 -for new and interested users.
   1.283 +MH-like email tool chests should be kept alive as they fill a market
   1.284 +niche by providing conceptional elegance and unique scripting qualities.
   1.285 +Mmh tries to create a modern and convenient entry point to MH-like
   1.286 +systems for new and interested users.
   1.287  .P
   1.288  The mmh project is motivated by deficits of nmh and
   1.289 -my wish for general changes, combined
   1.290 -with the nmh community's reluctancy to change.
   1.291 -.P
   1.292 -At that time, nmh had not adjusted to modern emailing needs well enough.
   1.293 +by my wish for general changes.
   1.294 +At the time the mmh project started, nmh had not yet adjusted to
   1.295 +modern emailing needs well enough.
   1.296  The default setup was completely unusable for modern emailing.
   1.297  Too much setup work was required.
   1.298 -Several modern features were already available but the community
   1.299 -did not want to have them as default.
   1.300 -Mmh is a way to change this.
   1.301 +Several modern features were already available,
   1.302 +but the community did not want to have them active by default.
   1.303 +Mmh is my way to change this.
   1.304  .P
   1.305 -In my eyes, MH's concepts could be exploited even better and
   1.306 -the style of the tools could be improved. Both would simplify
   1.307 -and generalize the system, providing cleaner interfaces and more
   1.308 -software leverage at the same time.
   1.309 -Mmh is a way to demonstrate this.
   1.310 +In my eyes, MH's concepts could be exploited better and
   1.311 +the style of the tools could be improved.
   1.312 +Both would simplify and generalize the system, providing cleaner
   1.313 +interfaces and greater software leverage at the same time.
   1.314 +Mmh is my way to demonstrate this.
   1.315  .P
   1.316 -In providing several parts of an email system, nmh can hardly
   1.317 +In providing multiple parts of the email system, nmh can hardly
   1.318  compete with the large specialized projects that focus
   1.319 -on only one of the components.
   1.320 -The situation can be improved by concentrating the development power
   1.321 +on one of the components only.
   1.322 +The situation could be improved by concentrating the development power
   1.323  on the most unique part of MH and letting the user pick his preferred
   1.324  set of other mail components.
   1.325  Today's pre-packaged software components encourage this model.
   1.326 -Mmh is a way to go for this approach.
   1.327 +Mmh is my way to provide this.
   1.328  .P
   1.329  It is worthwhile to fork nmh for the development of mmh,
   1.330  because the two projects focus on different goals and differ in
   1.331 @@ -363,7 +330,7 @@
   1.332  .[
   1.333  nmh-workers schnalke understanding nmh
   1.334  .]
   1.335 -In developing a separate experimental version new approaches can
   1.336 +In developing a separate experimental version, new approaches can
   1.337  easily be tried out without the need to discuss changes beforehand.
   1.338  In fact, revolutionary changes are hardly possible otherwise.
   1.339  .P
   1.340 @@ -379,10 +346,9 @@
   1.341  Any effort needs to be targeted towards a specific goal
   1.342  in order to be successful.
   1.343  Therefore, a description of an imagined typical mmh user follows.
   1.344 -Mmh should satisfy his needs.
   1.345 -Actually, as mmh is my personal version of MH, this is a description
   1.346 -of myself.
   1.347 -Writing software for oneself is a reliable way to produce software
   1.348 +Actually, as mmh is my personal version of MH,
   1.349 +this is sort of a description of myself.
   1.350 +Developing software for one's own is a reliable way to produce software
   1.351  that matches the user's desires.
   1.352  .P
   1.353  The target user of mmh likes Unix and its philosophy.
   1.354 @@ -392,24 +358,24 @@
   1.355  productivity by scripting the mail system.
   1.356  He uses modern email features, such as attachments,
   1.357  non-ASCII text, digital signatures and message encryption in a natural way.
   1.358 -He is able to set up mail system components,
   1.359 -and like to have the choice to pick the ones he prefers.
   1.360 +He is able to set up mail system components
   1.361 +and likes to pick the ones he prefers.
   1.362  He has a reasonably modern operating system that complies to the
   1.363  POSIX and ANSI C standards.
   1.364  .P
   1.365  The typical user invokes mmh commands directly in an interactive
   1.366 -shell session, but he uses them to automate mail handling tasks as well.
   1.367 +shell session, even on workstations where graphical front-ends could
   1.368 +be added.
   1.369  Likely, he runs his mail setup on a server machine,
   1.370  to which he connects via ssh.
   1.371 -He might also have a local mmh installation on his workstation.
   1.372 -Still, he tend to use mmh directly in the shell instead
   1.373 -of using graphical front-ends.
   1.374 -He definitely wants to be flexible and thus be able to change
   1.375 +He might automate mail processing with mmh tools
   1.376 +but definitely he uses the tools to build better tools.
   1.377 +In any case, he wants to have the flexibility to change
   1.378  his setup to suit his needs.
   1.379  .P
   1.380  The typical mmh user is a programmer.
   1.381 -He likes to, occasionally, take the opportunity of free software to put
   1.382 -hands on and get involved in the software he uses.
   1.383 +He likes to, occasionally, make use of the opportunity of free software
   1.384 +by putting hands on and getting involved in software he uses.
   1.385  In consequence, he likes small and clean code bases and cares for
   1.386  code quality.
   1.387  In general, he believes that:
   1.388 @@ -420,36 +386,33 @@
   1.389  .BU
   1.390  Code optimizations for anything but readability should be avoided.
   1.391  .BU
   1.392 +Removed code is debugged code.
   1.393 +.BU
   1.394  Having a lot of choice is bad.
   1.395 -.BU
   1.396 -Removed code is debugged code.
   1.397  
   1.398  
   1.399 -.U2 "Goals
   1.400 -.P
   1.401 -The general goals for the mmh project are the following:
   1.402 +.U2 "Goals of the mmh Project
   1.403  .IP "Streamlining
   1.404  Mmh should be stripped down to its core, which is the user agent (MUA).
   1.405  The feature set should be distilled to the indispensable ones,
   1.406  effectively removing corner cases.
   1.407  Parts that do not add to the main task of being a conceptionally
   1.408  appealing user agent should be removed.
   1.409 -This includes the mail submission and mail retrieval facilities.
   1.410 +This includes the mail transfer and mail retrieval facilities.
   1.411  Choice should be reduced to the main options.
   1.412  All tools should be tightly shaped.
   1.413  .IP "Modernizing
   1.414  Mmh's feature set needs to become more modern.
   1.415 -Better support for attachments, digital signatures and message encryption
   1.416 -should be added.
   1.417 +Better support for attachments, digital signatures, and message
   1.418 +encryption should be added.
   1.419  MIME support should be integrated deeper and more naturally.
   1.420  The modern email features need to be readily available, out-of-the-box.
   1.421 -On the other hand,
   1.422 -bulletin board support and similar obsolete facilities can be dropped out.
   1.423 -Likewise, ancient technologies should not be supported any further.
   1.424 -The available concepts need to be expanded as far as possible.
   1.425 +On the other hand, obsolete facilities can be dropped out and
   1.426 +ancient technologies need not be further supported.
   1.427 +The available concepts should be expanded as far as possible.
   1.428  A small set of concepts should recur consistently.
   1.429  .IP "Styling
   1.430 -Mmh's source code needs to be updated to modern standards.
   1.431 +Mmh's source code should be updated to modern standards.
   1.432  Standardized library functions should replace non-standard versions
   1.433  whenever possible.
   1.434  Code should be separated into distinct modules when feasible.