docs/master

diff intro.roff @ 207:e0e49a8bfbe8

Added refs.
author markus schnalke <meillo@marmaro.de>
date Thu, 12 Jul 2012 11:50:32 +0200
parents 8c0d5bd92f0b
children fead1fc981f0
line diff
     1.1 --- a/intro.roff	Thu Jul 12 11:36:44 2012 +0200
     1.2 +++ b/intro.roff	Thu Jul 12 11:50:32 2012 +0200
     1.3 @@ -26,6 +26,9 @@
     1.4  influenced the world more in being a set of system design concepts
     1.5  than in being a specific software product.
     1.6  The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
     1.7 +.[
     1.8 +gancarz unix philosophy
     1.9 +.]
    1.10  MH follows this philosophy.
    1.11  
    1.12  .U2 "History
    1.13 @@ -34,12 +37,17 @@
    1.14  proposed the design
    1.15  of a new mail handling system, called \fIMail Handler\fP (MH),
    1.16  to superseed RAND's old monolithic \fIMail System\fP (MS).
    1.17 +.[
    1.18 +shapiro gaines mh proposal
    1.19 +.]
    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's existence, the concept was
    1.23  believed to be practically unusable.
    1.24 -But the prototype proved successful and replaced MS thereafter.
    1.25 -In replacing MS, MH grew to provide anything necessary for emailing.
    1.26 +But the prototype proved successful and replaced MS thereafter.\&
    1.27 +.[
    1.28 +history of mh website
    1.29 +.]
    1.30  .P
    1.31  In the early eighties,
    1.32  the University of California at Irvine (UCI) started to use MH.
    1.33 @@ -47,18 +55,22 @@
    1.34  They took over the development and pushed MH forward.
    1.35  RAND had put the code into the public domain by then.
    1.36  MH was developed at UCI at the time when the Internet appeared,
    1.37 -when the University of California at Berkeley (UCB) implemented
    1.38 -the TCP/IP stack, and when Eric Allman wrote Sendmail.
    1.39 +the University of California at Berkeley (UCB) added TCP/IP
    1.40 +networking to their distribution, and Eric Allman wrote Sendmail.
    1.41  MH was extended as emailing became more featured.
    1.42  The development of MH was closely related to the development of email
    1.43  RFCs.
    1.44  In the advent of the \fIMultipurpose Internet Mail Extensions\fP (MIME),
    1.45  MH was one of the first implementations of the new email standard.
    1.46 +MH grew to provide anything necessary for emailing.
    1.47  .P
    1.48  In the nineties, the Internet became popular and in December 1996,
    1.49  Richard Coleman initiated the \fINew Mail Handler\fP (nmh) project.
    1.50  Nmh is a fork of MH 6.8.3 and bases strongly on the
    1.51  \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
    1.52 +.[
    1.53 +lbl changes
    1.54 +.]
    1.55  Colman intended to modernize MH and improve its portability and
    1.56  MIME handling capabilities.
    1.57  This should be done openly within the Internet community.
    1.58 @@ -97,76 +109,77 @@
    1.59  with others.
    1.60  .P
    1.61  Messages are named by their numeric filename,
    1.62 -but they can have symbolic names, too.
    1.63 -These are either automatically updated
    1.64 -position names such as the next or the last message,
    1.65 +but they can have symbolic names, as well.
    1.66 +These are either one of six system-controlled position names
    1.67  or user-settable group names for arbitrary sets of messages.
    1.68  These names are called sequences.
    1.69 -Sequences can be bound to the containing folder or to the context.
    1.70 +Automatically updated position names exist for the
    1.71 +first, last, previous, next, current message, and
    1.72 +for the number one beyond the last message.
    1.73 +(In mmh, the names of these sequences are abbreviated to the
    1.74 +first character.)
    1.75 +User-definded sequences can be bound to the folder containing the
    1.76 +messages (\fIpublic sequences\fP) or to the user's context
    1.77 +(\fIprivate sequences\fP).
    1.78  .P
    1.79 -The user's \fIprofile\fP is a file that contains his MH configuration.
    1.80 +The user's \fIprofile\fP is the file that contains his MH configuration.
    1.81  Default switches for the individual tools can be specified to
    1.82  adjust them to the user's personal preferences.
    1.83 +These switches will be automatically supplied whenever the specific
    1.84 +tool is invoked.
    1.85  Additionally, a single command can be linked under different names
    1.86 -with different default values easily.
    1.87 -Form templates for new messages or for replies are easily changeable,
    1.88 -and output is adjustable with format files.
    1.89 -Almost every part of the system can be adjusted to personal preference.
    1.90 +with different default values.
    1.91 +Form templates for new messages and replies, as well as format files
    1.92 +to adjust the output of tools are easily exchanged in the profile.
    1.93  .P
    1.94 -The system is well scriptable and extensible.
    1.95 -New MH tools are built out of or on top of existing ones quickly.
    1.96 -Furthermore, MH encourages the user to tailor, extend and automate the system.
    1.97 -As the MH tool chest was modeled after the Unix tool chest, the
    1.98 -properties of the latter apply to the former as well.
    1.99 -
   1.100 -
   1.101 -.ig \"XXX
   1.102 -
   1.103 -.P
   1.104 -To ease typing, the switches can be abbreviated as much as the remaining
   1.105 +Switches consist of a single dash (`\fL-\fP') followed by a word.
   1.106 +To ease typing, the word can be abbreviated, given the remaining
   1.107  prefix remains unambiguous.
   1.108 -If in our example no other switch would start with the letter `t', then
   1.109 +If no other switch starts with the letter `t', then any of
   1.110  .Cl "-truncate" ,
   1.111  .Cl "-trunc" ,
   1.112  .Cl "-tr" ,
   1.113  and
   1.114  .Cl "-t
   1.115 -would all be the same.
   1.116 +is equal.
   1.117  As a result, switches can neither be grouped (as in
   1.118  .Cl "ls -ltr" )
   1.119  nor can switch arguments be appended directly to the switch (as in
   1.120  .Cl "sendmail -q30m" ).
   1.121 -.P
   1.122  Many switches have negating counter-parts, which start with `no'.
   1.123  For example
   1.124  .Cl "-notruncate
   1.125  inverts the
   1.126  .Cl "-truncate
   1.127  switch.
   1.128 -They exist to undo the effect of default switches in the profile.
   1.129 -If the user has chosen to change the default behavior of some tool
   1.130 -by adding a default switch to the profile,
   1.131 -he can still undo this change in behavior by specifying the inverse
   1.132 -switch on the command line.
   1.133 +They exist to override the effect of default switches in the profile.
   1.134 +.P
   1.135 +The system is well scriptable and extensible.
   1.136 +Almost every part of the system can be adjusted to personal preference.
   1.137 +New MH tools are built out of or on top of existing ones quickly.
   1.138 +Furthermore, MH encourages the user to tailor, extend, and automate
   1.139 +the system.
   1.140 +As the MH tool chest was modeled after the Unix tool chest, the
   1.141 +properties of the latter apply to the former as well.
   1.142  
   1.143 -..
   1.144  
   1.145  
   1.146  .U2 "Using MH
   1.147  .P
   1.148 -It is strongly recommended to have a look at the MH Book,
   1.149 -which offers a thorough introduction to using MH.
   1.150 +It is strongly recommended to have a look at the \fIMH Book\fP,
   1.151  .[ [
   1.152  peek mh book
   1.153  .], Part II]
   1.154 -Rose and Romine provide a deeper and more technical
   1.155 -though slightly outdated introduction in only about two dozen pages.
   1.156 +which introduces into using MH.
   1.157 +Rose and Romine provide a deeper and more technical,
   1.158 +though slightly outdated, introduction in only about two dozen pages.
   1.159  .[
   1.160  rose romine real work
   1.161  .]
   1.162  .P
   1.163 -Following is an example mail handling session.
   1.164 -It uses mmh but is mostly compatible with nmh and old MH.
   1.165 +Following here is an example mail handling session.
   1.166 +Although it uses mmh, it is mostly compatible with nmh and the
   1.167 +original MH.
   1.168  Details might vary but the look and feel is the same.
   1.169  
   1.170  .so input/mh-session
   1.171 @@ -263,21 +276,27 @@
   1.172  The name \fImmh\fP may stand for \fImodern mail handler\fP,
   1.173  because the project tries to modernize nmh.
   1.174  Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
   1.175 -emphasizing that the project follows my visions and preferences.
   1.176 +emphasizing that the project is my version of nmh,
   1.177 +following my visions and preferences.
   1.178  (My login name is \fImeillo\fP.)
   1.179  This project model was inspired by \fIdwm\fP,
   1.180 -.\" XXX Ref
   1.181 +.[
   1.182 +dwm website
   1.183 +.]
   1.184  which is Anselm Garbe's personal window manager \(en
   1.185  targeted to satisfy Garbe's personal needs whenever conflicts appear.
   1.186  Dwm had retained its lean elegance and its focused character, whereas
   1.187 -its community-driven predecessor \fIwmii\fP had grown fat over time.
   1.188 -.\" XXX ref
   1.189 +its community-driven predecessor \fIwmii\fP
   1.190 +.[
   1.191 +wmii website
   1.192 +.]
   1.193 +had grown fat over time.
   1.194  The development of mmh should remain focused.
   1.195  
   1.196  
   1.197  .U2 "Motivation
   1.198  .P
   1.199 -MH is the most important of very few command line tool chest email systems.
   1.200 +MH is the most important of very few email systems in a tool chest style.
   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 @@ -321,6 +340,9 @@
   1.205  fundamental questions.
   1.206  The nmh community's reluctance regarding change conflicts
   1.207  with my strong desire for it.
   1.208 +.[
   1.209 +nmh-workers schnalke understanding nmh
   1.210 +.]
   1.211  In developing a separate experimental version new approaches can
   1.212  easily be tried out without the need to discuss changes beforehand.
   1.213  In fact, revolutionary changes are hardly possible otherwise.