--- a/summary.roff	Wed Jul 11 15:53:53 2012 +0200
+++ b/summary.roff	Wed Jul 11 18:35:11 2012 +0200
@@ -1,12 +1,12 @@
 .H0 "Summary
 .P
 This document describes and explains my work on mmh.
-I have streamlined the project by removing programs, facilities
+I have streamlined the project by removing programs, facilities,
 and options that diverted from the main task of mmh, being an MUA.
 I have modernized the code base removing obsolete functions and
 activating modern features per default.
-Furthermore, I improved the style by refactoring clumpsy code
-and by defining or forcing clear concepts.
+Furthermore, I have improved the style by refactoring clumpsy code
+and by identifying and forcing clear concepts.
 All my work was motivated by Antoine de Saint Exupery's well-known
 statement:
 .[
@@ -16,47 +16,46 @@
 It seems that perfection is attained not when there is nothing
 more to add, but when there is nothing more to remove.
 .QE
-.P
-In contrast to the common expectations, I have hardly added new features.
-I regard my improvements in selecting the relevant set of existing
-features and exploiting the concepts more thoroughly.
+.LP
+Against the common expectations, I hardly added new features.
+I regard my achievement in the selection of the relevant set of existing
+features, the choice of sensible defaults, and the extensive
+focus on structure and concepts.
 I believe, the result is a system simpler and clearer for both
 developing and using, without lacking important functionality.
 
+.KS
+.in 1c
+.so input/sloc.grap
+.KE
+
 
 .U2 "Outlook
 .P
-The work done during the project is not finished. \" XXX yet?
+The work on mmh is not finished.
 Several tasks are left to do.
 .P
-MIME handling is the most complex part of mmh and it requires
-general rework.
-.\" XXX rewrite these sentences for more smoothness
-The changes already accomplished build upon
-the existing structure only.
-To integrate it fully into the concepts.
-For instance, accessing messages and accessing MIME parts of messages
-have inherently different concepts, although a single concept should
-cover both.
-The sequence notation should provide a way to address MIME parts directly
-and should be more powerful in general. \" XXX more powerful
+MIME handling is the most complex part of mmh and the one with the
+highest potential for improvements.
+The changes already accomplished so far build upon the existing structure,
+but deeper rework is necessary to integrate MIME handling consistently.
+For instance, accessing messages and accessing their MIME parts
+should both covered by a single approach.
+This requires the sequence notation to provide a way to address
+MIME parts directly.
+In general, the sequence notation should become more powerful.
 For instance, it is currently not possible to access the second last
 message in a given sequence.
-Also, displaying messages with
-.Pn show
-requires further rework.
+Furthermore, displaying messages can be improved.
 Encrypted messages should be decoded automatically
-and digital signatures should be verified on-the-fly.
-The whole task should be aligned with the common behavior of other
-mail clients.
-MH's unique features should not be lost, but the default should become
-less surprising.
-Transfer-decoding of the quoted text in replies and encoding of non-ASCII
-characters in message header fields like
-.Hd Subject
-remain unsolved.
+and digital signatures verified on-the-fly.
+In this rework, MH's unique features need to be preserved,
+but as well the default behavior should become less surprising.
+Still, encoding and decoding is not done everywhere it is necessary.
+The problems of not decoded quotations of the original message in replies
+and not encoded non-ASCII characters in the message header remain.
 .P
-Some of mmh's tools were hardly touched during my work.
+Some of mmh's tools were hardly touched, yet.
 Among them are
 .Pn dist ,
 .Pn rcvdist ,
@@ -64,31 +63,26 @@
 .Pn pick ,
 and
 .Pn sortm .
+They should be refactored as well.
 Related to
-.Pn sortm ,
-a threaded message view is completely missing in mmh, so far.
+.Pn sortm
+is the threaded message view, which is completely missing, so far.
 .Pn pick
-could be enhanced by message indexing.
+could profit from message indexing.
 These fields deserve further research.
 .P
-The features most often asked for are Maildir and IMAP support.
+Nmh's testing framework has not been updated for mmh, yet.
+All refactoring had been done without the safety net of a test framework.
+Hence, experience warns that there may be subtle bugs in the code base.
+.P
+The features most often asked for are IMAP and Maildir support.
 But, both of them collide with MH in the same fundamental way as
-different filesystem approaches would collide with Unix.
-Nevertheless, an abstraction layer could provide a mapping from such
-storage back-ends to the MH storage format.
-Or the mmh tool chest could be reworked to operate on a generic back-end,
+different filesystem approaches collide with Unix.
+Nevertheless, an abstraction layer could provide a mapping between such
+storage back-ends and the MH storage format.
+Or, the mmh tool chest could be reworked to operate on a generic back-end,
 making the MH storage format only one of many possible back-ends.
 Research in this area is highly appreciated.
-.\" XXX targeting the right problems?!
-.P
-Nmh has a testing framework that supported the developers by detecting
-several subtle bugs.
-All refactoring in mmh had been done without the safety net of a test
-framework.
-Hence, experience warns that the probability for subtle bugs lurking
-in the code base is high.
-Nmh's test framework should be adjusted to mmh and extended.
-.\" XXX path notation; signing and encrypting
 
 
 .U2 "Relationship to nmh