docs/master

changeset 17:b3c37947764e

Several minor text improvements.
author markus schnalke <meillo@marmaro.de>
date Sun, 22 Apr 2012 17:16:30 +0200
parents 81f703140554
children db3567c9cc3f
files ch03.roff
diffstat 1 files changed, 13 insertions(+), 12 deletions(-) [+]
line diff
     1.1 --- a/ch03.roff	Sun Apr 22 13:50:35 2012 +0200
     1.2 +++ b/ch03.roff	Sun Apr 22 17:16:30 2012 +0200
     1.3 @@ -133,7 +133,7 @@
     1.4  draft folder facility exists. It had been introduced already in July 1984
     1.5  by Marshall T. Rose. The facility was deactivated by default.
     1.6  Even in nmh, the draft folder facility remained deactivated by default.
     1.7 -At least, Richard Coleman added the man page \fImh-draft(5)\fI to document
     1.8 +At least, Richard Coleman added the man page \fImh-draft(5)\fP to document
     1.9  the feature well.
    1.10  .P
    1.11  The only advantage of not using the draft folder facility is the static
    1.12 @@ -145,9 +145,9 @@
    1.13  On the other hand, a draft folder is the much more natural concept than
    1.14  a draft message. MH's mail storage consists of folders and messages,
    1.15  the messages named with ascending numbers. A draft message breaks with this
    1.16 -concept by introducing a message in a file named ``draft''. This draft
    1.17 +concept by introducing a message in a file named ``\fLdraft\fP''. This draft
    1.18  message is special. It can not be simply listed with the available tools,
    1.19 -but instead special switches were required. I.e. corner-cases were
    1.20 +but instead requires special switches. I.e. corner-cases were
    1.21  introduced. A draft folder, in contrast, does not introduce such
    1.22  corner-cases. The available tools can operate on the messages within that
    1.23  folder like on any messages within any mail folders. The only difference
    1.24 @@ -157,7 +157,7 @@
    1.25  The trivial part of the change was activating the draft folder facility
    1.26  by default and setting a default name for this folder. Obviously, I chose
    1.27  the name ``\fL+drafts\fP''. This made the \fL\-draftfolder\fP and
    1.28 -\fL\-draftmessage\fP switches useless, thus I could remove them two.
    1.29 +\fL\-draftmessage\fP switches useless, and I could remove them.
    1.30  The more difficult but also the part that showed the real improvement,
    1.31  was updating the tools to the new concept. \fL\-draft\fP switches could
    1.32  be dropped, as operating on a draft message became indistinguishable to
    1.33 @@ -167,10 +167,10 @@
    1.34  an existing draft. In either case, the behavior of \fLcomp\fP is
    1.35  deterministic. There is no more need to query the user. I consider this
    1.36  a major improvement. By making \fLsend\fP simply operate on the current
    1.37 -message in the draft folder by default, with both, message and folder,
    1.38 +message in the draft folder by default, with message and folder both
    1.39  overridable by specifying them on the command line, it is now possible
    1.40 -to send any message in the storage by simply specifying its folder and
    1.41 -name.
    1.42 +to send a draft anywhere within the storage by simply specifying its folder
    1.43 +and name.
    1.44  .P
    1.45  All theses changes converted special cases to regular cases, thus
    1.46  simplifying the tools and increasing the flexibility.
    1.47 @@ -193,8 +193,8 @@
    1.48  the backup prefix from the file name. If however, the last message of
    1.49  a folder is been removed \(en say message `\fL6\fP' becomes file
    1.50  `\fL,6\fP' \(en and a new message enters the same folder, thus the same
    1.51 -numbered being given again \(en in out case `\fL6\fP' \(en, if that one
    1.52 -is removed too, then the backup of the former message gets over written.
    1.53 +numbered being given again \(en in our case `\fL6\fP' \(en, if that one
    1.54 +is removed too, then the backup of the former message gets overwritten.
    1.55  Thus, the ability to restore removed messages does not only depend on
    1.56  the ``sweeping cron job'' but also on the removing of further messages.
    1.57  This is undesireable, because the real mechanism is hidden from the user
    1.58 @@ -208,7 +208,7 @@
    1.59  instead of taking the default action, described above.
    1.60  Refiling the to-be-removed files to some wastebin folder was a common
    1.61  example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP'
    1.62 -(implemented through a shell alias) and `\fLrm `mhpath +d all`\fP'
    1.63 +to move messages to the wastebin and `\fLrm `mhpath +d all`\fP'
    1.64  the empty the wastebin.
    1.65  Managing the message removal this way is a sane approach. It keeps
    1.66  the removed messages in one place, makes it easy to remove the backup
    1.67 @@ -233,9 +233,10 @@
    1.68  of moved to the trash folder.
    1.69  
    1.70  
    1.71 -.H1 "Paths to ...
    1.72 +.H1 "MH Directory Split
    1.73  .P
    1.74 -foo
    1.75 +
    1.76 +
    1.77  
    1.78  .H1 "Path Notations
    1.79  .P