diff discussion.roff @ 179:b59201e345e5

Applied further corrections by Aaron.
author markus schnalke <meillo@marmaro.de>
date Tue, 10 Jul 2012 23:13:45 +0200
parents 520b3c7abba1
children 731e747a805b
line wrap: on
line diff
--- a/discussion.roff	Tue Jul 10 22:30:17 2012 +0200
+++ b/discussion.roff	Tue Jul 10 23:13:45 2012 +0200
@@ -1657,8 +1657,8 @@
 Hence, others can comprehend my view and argue for undoing the change
 if I have missed an important aspect.
 I was quick in dropping parts.
-I rather re-included falsely dropped parts than going at a slower pace.
-Mmh is experimental work; it required tough decisions.
+I rather include falsely dropped parts again, than going at a slower pace.
+Mmh is experimental work; it requires tough decisions.
 .\" XXX ``exp. work'' schon oft gesagt
 
 
@@ -1970,8 +1970,8 @@
 The conversion to MIME is invisible to the user.
 The draft stored in the draft folder is always in source form with
 attachment headers.
-If the MIMEification fails, for instance because the file to attach
-is not accessible, the original draft is not changed.
+If the MIMEification fails (e.g. because the file to attach
+is not accessible) the original draft is not changed.
 .P
 The attachment system handles the forwarding of messages, too.
 If the attachment header value starts with a plus character (`\fL+\fP'),
@@ -1992,7 +1992,7 @@
 .Pe automimeproc
 profile entry could be specified to have the `mime' command invoked
 automatically each time.
-Unfortunately, this approach conflicted with attachment system
+Unfortunately, this approach conflicted with the attachment system
 because the draft would already be in MIME format at the time
 when the attachment system wanted to MIMEify it.
 To use nmh's attachment system, `mime' must not be called at the
@@ -2048,7 +2048,7 @@
 partly intelligent work.
 Forcing the user to find out the correct MIME type,
 forces him to do partly mechanical work.
-Letting the computer do the work, can lead to bad choices for difficult
+Letting the computer do the work can lead to bad choices for difficult
 content.
 For mmh, the latter option was chosen.
 .P
@@ -2235,6 +2235,7 @@
 .Pn show
 program, because it was not capable to display MIME messages
 and is no longer part of mmh.
+.\" XXX ref to other section
 Although
 .Pn mhshow
 was renamed to
@@ -2242,7 +2243,6 @@
 in mmh, this section uses the name
 .Pn mhshow ,
 in order to avoid confusion.
-.\" XXX ref to other section
 .P
 In mmh, the basic idea is that
 .Pn mhshow
@@ -2286,7 +2286,7 @@
 .Sw -serialonly
 switch of
 .Pn mhshow .
-As MIME parts are always processed exclusively , i.e. serially,
+As MIME parts are always processed exclusively, i.e. serially,
 the `%e' escape in
 .Pe mhshow-show-*
 profile entries became useless and was thus removed.
@@ -2765,7 +2765,7 @@
 before they truly used the system,
 although they had been motivated in the beginning.
 They suffer hard enough to get used to the tool chest approach,
-we should spare them further inconveniences.
+we developers should spare them further inconveniences.
 .P
 Maintaining compatibility for its own sake is bad,
 because the code base collects more and more compatibility code.
@@ -3813,7 +3813,7 @@
 The source code of the mmh tools is located in the
 .Fn uip
 (``user interface programs'') directory.
-Each tools has a source file with the same name.
+Each tools has a source file with the name of the command.
 For example,
 .Pn rmm
 is built from
@@ -3841,7 +3841,7 @@
 Most of the mmh tools, however, are simple and straight-forward programs.
 With the exception of the MIME handling tools,
 .Pn pick
-is the largest tools.
+is the largest tool.
 It contains 1\|037 lines of source code (measured with
 .Pn sloccount ), excluding the MH library.
 Only the MIME handling tools (\c
@@ -3854,9 +3854,9 @@
 source files seldom leads to better readability.
 For such tools, splitting makes sense
 when parts of the code are reused in other programs,
-and the reused code fragment is not general enough
-for including it in the MH library,
-or, if the code has dependencies on a library that only few programs need.
+and the reused code fragment is (1) not general enough
+for including it in the MH library
+or (2) has dependencies on a library that only few programs need.
 .Fn uip/packsbr.c ,
 for instance, provides the core program logic for the
 .Pn packf
@@ -4021,7 +4021,7 @@
 does annotate and send messages.
 In nmh, there surely exists the tool
 .Pn send ,
-which does (almost) only send messages.
+which does mainly send messages.
 But
 .Pn comp
 and
@@ -4034,7 +4034,7 @@
 .Pn whatnow
 and
 .Pn viamail ,
-they all (!) have the same message sending function included, too.
+they all (!) have the same message sending function included, as well.
 In result,
 .Pn comp
 sends messages without using