docs/master

changeset 180:731e747a805b

Applied corrections by Lydi.
author markus schnalke <meillo@marmaro.de>
date Wed, 11 Jul 2012 00:00:34 +0200
parents b59201e345e5
children eb6eeb10afd5
files discussion.roff
diffstat 1 files changed, 23 insertions(+), 14 deletions(-) [+]
line diff
     1.1 --- a/discussion.roff	Tue Jul 10 23:13:45 2012 +0200
     1.2 +++ b/discussion.roff	Wed Jul 11 00:00:34 2012 +0200
     1.3 @@ -3080,7 +3080,7 @@
     1.4  .Sw -list .
     1.5  .P
     1.6  Trying to fix these problems on the surface would not have solved
     1.7 -them truly, as they originate from a discrepance between the semantic
     1.8 +them truly, as they originate from a discrepance between the
     1.9  structure of the problem and the structure implemented in the program.
    1.10  Such structural differences can not be cured on the surface.
    1.11  They need to be solved by adjusting the structure of the implementation
    1.12 @@ -3102,7 +3102,8 @@
    1.13  Historically,
    1.14  .Pn anno
    1.15  had only one operation mode: adding header fields.
    1.16 -With the extension, it got two more modes:
    1.17 +With the extension it got two more modes:
    1.18 +.\" XXX got
    1.19  listing and deleting header fields.
    1.20  The structure of the code changes did not pay respect to this
    1.21  fundamental change to
    1.22 @@ -3187,6 +3188,7 @@
    1.23  .P
    1.24  To allow MH tools to understand all four notations,
    1.25  they need to convert between them.
    1.26 +.\" XXX between?
    1.27  In nmh, these path name conversion functions were located in the files
    1.28  .Fn sbr/path.c
    1.29  (``return a pathname'') and
    1.30 @@ -3287,6 +3289,7 @@
    1.31  path name.
    1.32  The result is a pointer to static memory.
    1.33  .P
    1.34 +.\" XXX ueberfluessig?
    1.35  The new functions have names that indicate their use.
    1.36  Two of the functions convert relative to absolute path names of the
    1.37  same type.
    1.38 @@ -3327,6 +3330,7 @@
    1.39  .P
    1.40  .Fn sbr/path.c
    1.41  now contains all path handling code.
    1.42 +.\" XXX naechste zeile weg?
    1.43  Only 173 lines of code were needed to replace the previous 252 lines.
    1.44  The readability of the code is highly improved.
    1.45  Additionally, each of the six exported and one static functions
    1.46 @@ -3412,7 +3416,7 @@
    1.47  Clear and simple concepts are a precondition for this.
    1.48  Hence, the real solution is having all MH tools read the profile.
    1.49  .P
    1.50 -Yet, the problem has a further aspect.
    1.51 +The problem has a further aspect.
    1.52  It mainly originates in
    1.53  .Pn mhmail .
    1.54  .Pn mhmail
    1.55 @@ -3464,7 +3468,7 @@
    1.56  to instruct them reading a different profile.
    1.57  .Pn mhmail
    1.58  could have set up a well-defined profile and caused all MH tools
    1.59 -in the session use it by exporting an environment variable.
    1.60 +in the session to use it by exporting an environment variable.
    1.61  With this approach, no special cases would have been introduced,
    1.62  no surprises would have been caused.
    1.63  By writing a clean-profile-wrapper, the concept could have been
    1.64 @@ -3548,7 +3552,7 @@
    1.65  that are standardized and thus widely available today,
    1.66  but were not back then.
    1.67  Today, twenty years after the POSIX and ANSI C were published,
    1.68 -developers can expect system to comply with these standards.
    1.69 +developers can expect systems to comply with these standards.
    1.70  In consequence, MH-specific replacements for standard functions
    1.71  can and should be dropped.
    1.72  Kernighan and Pike advise: ``Use standard libraries.''
    1.73 @@ -3561,7 +3565,7 @@
    1.74  .Fu snprintf()
    1.75  function, for instance, was standardized with C99 and is available
    1.76  almost everywhere because of its high usefulness.
    1.77 -In project's own implementation of
    1.78 +The project's own implementation of
    1.79  .Fu snprintf()
    1.80  was dropped in March 2012 in favor for using the one of the
    1.81  standard library.
    1.82 @@ -3570,7 +3574,8 @@
    1.83  if systems do not support these standardized and widespread functions.
    1.84  This compromise is made because mmh focuses on the future.
    1.85  .P
    1.86 -I am not yet thirty years old and my C and Unix experience comprises
    1.87 +.\" XXX kuerzen und mit dem naechsten Absatz vereinen
    1.88 +I am still in my twenties and my C and Unix experience comprises
    1.89  only half a dozen years.
    1.90  Hence, I need to learn about the history in retrospective.
    1.91  I have not used those ancient constructs myself.
    1.92 @@ -3579,7 +3584,7 @@
    1.93  All my programming experience is from a time when ANSI C and POSIX
    1.94  were well established already.
    1.95  I have only read a lot of books about the (good) old times.
    1.96 -This puts me in a difficult positions when working with old code.
    1.97 +This puts me in a difficult position when working with old code.
    1.98  I need to freshly acquire knowledge about old code constructs and ancient
    1.99  programming styles, whereas older programmers know these things by
   1.100  heart from their own experience.
   1.101 @@ -3629,7 +3634,8 @@
   1.102  .P
   1.103  The
   1.104  .Fu copy()
   1.105 -function copies the string in argument one to the location in two.
   1.106 +function copies the string in parameter one to the location in
   1.107 +parameter two.
   1.108  In contrast to
   1.109  .Fu strcpy() ,
   1.110  it returns a pointer to the terminating null-byte in the destination area.
   1.111 @@ -3734,6 +3740,7 @@
   1.112  They are different kinds of data:
   1.113  The data to be operated on and the configuration to change how
   1.114  tools operate.
   1.115 +.\" XXX bad ... inapropriate?
   1.116  Splitting the configuration between the profile and the MH directory
   1.117  is bad.
   1.118  Merging the mail storage and the configuration in one directory is bad
   1.119 @@ -3813,7 +3820,7 @@
   1.120  The source code of the mmh tools is located in the
   1.121  .Fn uip
   1.122  (``user interface programs'') directory.
   1.123 -Each tools has a source file with the name of the command.
   1.124 +Each tool has a source file with the name of the command.
   1.125  For example,
   1.126  .Pn rmm
   1.127  is built from
   1.128 @@ -3835,15 +3842,16 @@
   1.129  21 programs depend on one source file only.
   1.130  (These numbers and the ones in the following text ignore the MH library
   1.131  as well as shell scripts and multiple names for the same program.)
   1.132 +.\" XXX graph
   1.133  .P
   1.134  Splitting the source code of a large program into multiple files can
   1.135  increase the readability of its source code.
   1.136 -Most of the mmh tools, however, are simple and straight-forward programs.
   1.137 +.\" XXX however?
   1.138 +Most of the mmh tools are simple and straight-forward programs.
   1.139  With the exception of the MIME handling tools,
   1.140  .Pn pick
   1.141  is the largest tool.
   1.142 -It contains 1\|037 lines of source code (measured with
   1.143 -.Pn sloccount ), excluding the MH library.
   1.144 +It contains 1\|037 lines of source code, excluding the MH library.
   1.145  Only the MIME handling tools (\c
   1.146  .Pn mhbuild ,
   1.147  .Pn mhstore ,
   1.148 @@ -3988,7 +3996,8 @@
   1.149  .P
   1.150  Understanding
   1.151  .Pn comp
   1.152 -requires to read 210 lines of code in mmh, but ten times as much in nmh.
   1.153 +.\" XXX kate fragen: more vs. as much
   1.154 +requires to read 210 lines of code in mmh, but ten times more in nmh.
   1.155  Due to the aforementioned hack in
   1.156  .Pn anno
   1.157  to save the additional parameter, information passed through the program's