--- a/ch03.roff	Tue Jun 12 18:04:55 2012 +0200
+++ b/ch03.roff	Tue Jun 12 20:44:52 2012 +0200
@@ -419,20 +419,20 @@
 mapped message numbers and sequences to files and invoked
 .Pn mhl
 to have the files formated.
-For MIME, this approach wasn't sufficient anymore.
+With MIME, this approach wasn't sufficient anymore.
 MIME messages can consist of multiple parts, some of which aren't
-directly displayable, and text content might be encoded in
+directly displayable, further more text content might be encoded in
 foreign charsets.
 .Pn show 's
 understanding of messages and
 .Pn mhl 's
-limited display facilities couldn't cope with the task any longer.
+display capabilities couldn't cope with the task any longer.
 .P
-Instead of extending these tools, additional tools were written from scratch
-and then added to the MH tool chest. Doing so is encouraged by the
-tool chest approach. The new tools could be added without interfering
-with the existing ones.
-Modular design is a great advantage for extending a system.
+Instead of extending these tools, additional tools were written from
+scratch and added to the MH tool chest.
+Doing so is encouraged by the tool chest approach.
+Modular design is a great advantage for extending a system,
+as new tools can be added without interfering with existing ones.
 First, the new MIME features were added in form of the single program
 .Pn mhn .
 The command
@@ -441,27 +441,26 @@
 With the 1.0 release of nmh in February 1999, Richard Coleman finished
 the split of
 .Pn mhn
-into a set of specialized programs, which together covered the
-multiple aspects of MIME. One of these resulting tools was
+into a set of specialized tools, which together covered the
+multiple aspects of MIME.
+One of them was
 .Pn mhshow ,
-which replaced the
-.Cl "mhn -show
-call.
-It was capable to display a MIME message appropriately.
+which replaced
+.Cl "mhn -show" .
+It was capable of displaying MIME messages appropriately.
 .P
-From then on, two message display tools were part of nmh:
+From then on, two message display tools were part of nmh,
 .Pn show
 and
 .Pn mhshow .
-Because the user should not need to invoke the right tool
-whether the message uses MIME or not,
+To ease the life of users,
 .Pn show
 was extended to automatically hand the job over to
 .Pn mhshow
 if displaying the message would be beyond
 .Pn show 's
 abilities.
-In consequence, the user would invoke
+In consequence, the user would simply invoke
 .Pn show
 (possibly through
 .Pn next
@@ -472,61 +471,82 @@
 or
 .Pn mhshow ,
 whatever was more appropriate.
-(There was also a switch for
-.Pn show
-to never invoke
-.Pn mhshow .
-.Pn show
-was able to display MIME messages if they contained only a single text
-part.)
 .P
 Having two similar tools for essentially the same task is redundant.
-The development of both programs needed to be in sync,
+Usually,
+users wouldn't distinguish between
+.Pn show
+and
+.Pn mhshow
+in their daily mail reading.
+Having two separate display programs was therefore mainly unnecessary
+from a user's point of view.
+Besides, the development of both programs needed to be in sync,
 to ensure that the programs behaved in a similar way,
 because they were used like a single tool.
 Different behavior would have surprised the user.
 .P
 Today, non-MIME messages are rather seen to be a special case of
-MIME messages, than MIME messages are seen to be an extension to
-original email.
+MIME messages, although it's the other way round.
 As
 .Pn mhshow
-had already be able to display non-MIME messages, it was natural
+had already be able to display non-MIME messages, it appeared natural
 to drop
 .Pn show
 in favor of using
 .Pn mhshow
 exclusively.
-This decision followed the idea of orthogonal design.
+.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
+Removing
+.Pn show
+is no loss in function, because functionally
+.Pn mhshow
+covers it completely.
+The old behavior of
+.Pn show
+can still be emulated with the simple command line:
+.VS
+mhl `mhpath c`
+VE
+.P
 For convenience,
 .Pn mhshow
-was then renamed to
-.Pn show .
-.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
+was renamed to
+.Pn show
+after
+.Pn show
+was gone.
+It is clear that such a rename may confuse future developers when
+trying to understand the history.
+Nevertheless, I consider the convenience on the user's side,
+to call
+.Pn show
+when they want a message to be displayed, to outweigh the inconvenience
+on the developer's side when understanding the project history.
 .P
-To prepare for this transition,
+To prepare for the transition,
 .Pn mhshow
 was reworked to behave more like
 .Pn show
 first.
-(Section XXX describes this rework from a different perspective.)
-Once the tools behaved similar, the replacing became a natural decision.
-In mmh,
+(cf. Sec. XXX)
+Once the tools behaved more alike, the replacing appeared to be
+even more natural.
+Today, mmh's new
 .Pn show
-is the one single message display program again, but it handles
-MIME messages as well as non-MIME messages.
-Now, there's only one program to maintain, and users don't need to deal
-with the existance of two display programs.
+became the one single message display program again, with the difference
+that today it handles MIME messages as well as non-MIME messages.
+The outcome of the transition is one program less to maintain,
+no second display program for users to deal with,
+and less system complexity.
 .P
-There's one reason why removing the old
+Still, removing the old
 .Pn show
-hurts: It had been such a simple program.
-Its lean elegance is missing to
-.Pn mhshow ,
-i.e. the new
+hurts in one regard: It had been such a simple program.
+Its lean elegance is missing to the new
 .Pn show .
-But there is no chance, because supporting MIME causes essentially
-higher complexity.
+But there is no chance;
+supporting MIME demands for higher essential complexity.
 
 
 .H2 "Removal of Configure Options