docs/master: discussion.roff comparison

comparison discussion.roff @ 173:4c7db172fb59

Various corrections and improvements.

author	markus schnalke <meillo@marmaro.de>
date	Tue, 10 Jul 2012 17:26:05 +0200
parents	346ff7e201f5
children	3d7db5c7965d

comparison

equal deleted inserted replaced

-:6800d594b2b7
+:4c7db172fb59
 MH once provided anything necessary for email handling.
 The community around nmh has the similar understanding that nmh should
 provide a complete email system.
 In fundamental contrast, mmh shall be a MUA only.
 I believe that the development of all-in-one mail systems is obsolete.
-Today, email is too complex to be fully covered by single projects.
+Today, email is too complex to be fully covered by a single project.
-Such a project won't be able to excel in all aspects.
+Such a project will not be able to excel in all aspects.
 Instead, the aspects of email should be covered by multiple projects,
 which then can be combined to form a complete system.
 Excellent implementations for the various aspects of email already exist.
 Just to name three examples: Postfix is a specialized MTA,
 .\" XXX homepages verlinken
 or modular \(en will never be the best choice in any of the fields.
 Even in providing the best consistent all-in-one system, they are likely
 to be beaten by projects that focus only on integrating existing mail
 components to create a homogeneous system.
 .P
-The limiting resource in the community development of Free Software
+The limiting resource in the community development of free software
 is usually man power.
 .\" XXX FIXME ref!
 If the development power is spread over a large development area,
 it becomes even more difficult to compete with the specialists in the
 various fields.
 The question whether there is sense in having a fall-back pager in all
 the command line tools, for the cases when
 .Pn more
 or
 .Pn less
-aren't available, appears to be ridiculous.
+are not available, appears to be ridiculous.
 Of course, MSAs and MRAs are more complex than text pagers
 and not necessarily available but still the concept of orthogonal
 design holds: ``Write programs that do one thing and do it well.''
 .[
 mcilroy unix phil
 .H2 "Non-MUA Tools
 .P
 One goal of mmh is to remove the tools that are not part of the MUA's task.
-Further more, any tools that don't significantly improve the MUA's job
+Further more, any tools that do not significantly improve the MUA's job
 should be removed.
 Loosely related and rarely used tools distract from the lean appearance.
 They require maintenance work without adding much to the core task.
 By removing these tools, the project shall become more streamlined
 and focused.
 .Pn msh
 was removed
 .Ci 916690191222433a6923a4be54b0d8f6ac01bd02
 because the tool was in conflict with the philosophy of MH.
 It provided an interactive shell to access the features of MH,
-but it wasn't just a shell tailored to the needs of mail handling.
+but it was not just a shell tailored to the needs of mail handling.
 Instead, it was one large program that had several MH tools built in.
 This conflicts with the major feature of MH of being a tool chest.
 .Pn msh 's
 main use case had been accessing Bulletin Boards, which have ceased to
 be popular.
 had been MH's message display program.
 .Pn show
 mapped message numbers and sequences to files and invoked
 .Pn mhl
 to have the files formatted.
-With MIME, this approach wasn't sufficient anymore.
+With MIME, this approach was not sufficient anymore.
 MIME messages can consist of multiple parts. Some parts are not
 directly displayable and text content might be encoded in
 foreign charsets.
 .Pn show 's
 understanding of messages and
 .Pn mhl 's
-display capabilities couldn't cope with the task any longer.
+display capabilities could not cope with the task any longer.
 .P
 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,
 or
 .Pn mhshow ,
 whatever was more appropriate.
 .P
 Having two similar tools for essentially the same task is redundant.
-Usually,
+Usually, users would not distinguish between
-users wouldn't distinguish between
 .Pn show
 and
 .Pn mhshow
 in their daily mail reading.
 Having two separate display programs was therefore mainly unnecessary
 There is the cost of code complexity to be able to customize.
 There is the cost of less tested setups, because there are
 more possible setups and especially corner cases.
 Additionally, there is the cost of choice itself.
 The code complexity directly affects the developers.
-Less tested code affects both, users and developers.
+Less tested code affects both users and developers.
 The problem of choice affects the users, for once by having to choose,
 but also by more complex interfaces that require more documentation.
 Whenever options add few advantages but increase the complexity of the
 system, they should be considered for removal.
 I have reduced the number of project-specific configure options from
 .U3 "Backup Prefix
 .P
 The backup prefix is the string that was prepended to message
 filenames to tag them as deleted.
-By default it had been the comma character `\f(CW,\fP'.
+By default it had been the comma character (`\fL,\fP').
 .\" XXX Zeitlich ordnen
 In July 2000, Kimmo Suominen introduced
 the configure option
 .Sw --with-hash-backup
-to change the default to the hash symbol `\f(CW#\fP'.
+to change the default to the hash character `\f(CW#\fP'.
 The choice was probably personal preference, because first, the
 option was named
 .Sw --with-backup-prefix.
-and had the prefix symbol as argument.
+and had the prefix character as argument.
-But giving the hash symbol as argument caused too many problems
+But giving the hash character as argument caused too many problems
 for Autoconf,
-thus the option was limited to use the hash symbol as the default prefix.
+thus the option was limited to use the hash character as the default prefix.
 This supports the assumption, that the choice for the hash was
 personal preference only.
-Being related or not, words that start with the hash symbol
+Being related or not, words that start with the hash character
 introduce a comment in the Unix shell.
 Thus, the command line
 .Cl "rm #13 #15
 calls
 .Pn rm
-without arguments because the first hash symbol starts the comment
+without arguments because the first hash character starts the comment
 that reaches until the end of the line.
 To delete the backup files,
 .Cl "rm ./#13 ./#15"
 needs to be used.
 Using the hash as backup prefix can be seen as a precaution against
 .I "plussed user
 processing of sendmail.
 The decision to remove this username_extension masquerading was
 motivated by the fact that
 .Pn spost
-hadn't supported it already.
+had not supported it already.
 .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
 Username extensions are possible in mmh, but less convenient to use.
 .\" XXX covered by next paragraph
 .\" XXX format file %(getenv USERNAME_EXTENSION)
 .P
 .Cl "comp -editor prompter" ,
 the resulting behavior is similar to
 .Pn mailx .
 Apparently,
 .Pn prompter
-hadn't been touched lately.
+had not been touched lately.
 Otherwise it's hardly explainable why it
 still offered the switches
 .Sw -erase
 .Ar chr
 and
 The perception of the topic described in the RFCs is clearly visible
 in MH's implementation.
 .\" XXX rewrite ``no idea''.
 As a result,
 MH had all the MIME features but no idea of attachments.
-But users don't need all the MIME features,
+But users do not need all the MIME features,
 they want convenient attachment handling.
 .U3 "Composing MIME Messages
 .P
 attachment headers.
 If the MIMEification fails, for instance 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 (`+'),
+If the attachment header value starts with a plus character (`\fL+\fP'),
 like in
 .Cl "Attach: +bob 30 42" ,
 the given messages in the specified folder will be attached.
 This allowed to simplify
 .Pn forw .
 Mmh's current solution is even more elaborate.
 Any necessary MIMEification is done automatically.
 There is no `mime' command at the WhatNow prompt anymore.
 The draft will be converted automatically to MIME when either an
 attachment header or non-ASCII text is present.
-Furthermore, the hash character (`#') is not special any more
+Furthermore, the hash character (`\fL#\fP') is not special any more
 at line beginnings in the draft message.
 .\" XXX REF ?
 Users need not concern themselves with the whole topic at all.
 .P
 Although the new approach does not anymore support arbitrary MIME
 .ig
 .P
 mhshow/mhstore: Removed support for retrieving message/external-body parts.
-These tools won't download the contents automatically anymore. Instead,
+These tools will not download the contents automatically anymore. Instead,
 they print the information needed to get the contents. If someone should
 really receive one of those rare message/external-body messages, he can
 do the job manually. We save nearly a thousand lines of code. That's worth
 it!
 (The profile entry `nmh-access-ftp' and sbr/ruserpass.c for reading
 .U3 "Trash Folder
 .Id trash-folder
 .P
 Similar to the situation for drafts is the situation for removed messages.
 Historically, a message was ``deleted'' by prepending a specific
-\fIbackup prefix\fP, usually the comma character, to the file name.
+\fIbackup prefix\fP, usually the comma character,
+to the file name.
 The specific file would then be ignored by MH because only files with
 names consisting of digits only are treated as messages.
 Although files remained in the file system,
 the messages were no longer visible in MH.
 To truly delete them, a maintenance job was needed.
 just to allow them use MH in a convenient and modern way?
 Unless they are strongly convinced of the concepts, they will fail.
 I have seen friends of me giving up disappointed
 before they truly used the system,
 although they had been motivated in the beginning.
-They suffer hard enough to get used to the toolchest approach,
+They suffer hard enough to get used to the tool chest approach,
 we should spare them further inconveniences.
 .P
 Maintaining compatibility for its own sake is bad,
 because the code base collects more and more compatibility code.
 Sticking to the compatiblity code means remaining limited;
 Having identified the problem, I solved it by putting structure into
 .Pn anno
 and its documentation.
 .Ci d54c8db8bdf01e8381890f7729bc0ef4a055ea11
 .P
-The difference is visible in both, the code and the documentation.
+The difference is visible in both the code and the documentation.
 The following code excerpt:
 .VS
 int delete = -2;  /* delete header element if set */
 int list = 0;  /* list header elements if set */
 [...]
 The second parameter of
 .Fu path()
 defines the type of path given as first parameter.
 Directory paths are converted to absolute directory paths.
 Folder paths are converted to absolute folder paths.
-Folder paths must not include a leading `@' character.
+Folder paths must not include a leading `\fL@\fP' character.
 Leading plus characters are preserved.
 The result is a pointer to newly allocated memory.
 .LI 2
 .Fu pluspath()
 is a convenience-wrapper to
 This function can not be used for directory paths.
 An empty string parameter causes a buffer overflow.
 .LI 3
 .Fu m_mailpath()
 converts directory paths to absolute directory paths.
-The characters `+' or `@' at the beginning of the path name are
+The characters `\fL+\fP' or `\fL@\fP' at the beginning of the path name are
 treated literal, i.e. as the first character of a relative directory path.
 Hence, this function can not be used for folder paths.
 In any case, the result is an absolute directory path.
 The result is a pointer to newly allocated memory.
 .LI 4
 .Fu m_maildir()
 returns the parameter unchanged if it is an absolute directory path
-or begins with the entry `.' or `..'.
+or begins with the entry `\fL.\fP' or `\fL..\fP'.
 All other strings are prepended with the current working directory.
 Hence, this functions can not be used for folder paths.
 The result is either an absolute directory path or a relative
 directory path, starting with a dot.
 In contrast to the other functions, the result is a pointer to
 could have set up a well-defined profile and caused all MH tools
 in the session use it by exporting an environment variable.
 With this approach, no special cases would have been introduced,
 no surprises would have been caused.
 By writing a clean-profile-wrapper, the concept could have been
-generalized orthogonally to the whole MH toolchest.
+generalized orthogonally to the whole MH tool chest.
 Then Rose's motivation behind the decision that
 .Pn post
 ignores the profile, as quoted by Jeffrey Honig,
 .[
 nmh-workers post profile
 Mapping such problems on the concepts of switching between different
 profiles, solves them once for all.
 .P
 In mmh, the wish to have
 .Pn mhmail
-as as replacement for
+as a replacement for
 .Pn mailx
 is considered obsolete.
 Mmh's
 .Pn mhmail
 does no longer cover this use-case.
 will become an ordinary MH tool, reading the profile.
 If, however, this idea will not convince, then
 .Pn mhmail
 will be removed.
 .P
-Every program in the mmh toolchest reads the profile.
+Every program in the mmh tool chest reads the profile.
 The only exception is
 .Pn slocal ,
-which is not considered part of the mmh toolchest.
+which is not considered part of the mmh tool chest.
 This MDA is only distributed with mmh, currently.
 Mmh has no
 .Pn post
 program, but
 .Pn spost ,
 .Fu snprintf()
 was dropped in March 2012 in favor for using the one of the
 standard library.
 .Ci 0052f1024deb0a0a2fc2e5bacf93d45a5a9c9b32
 Such decisions limit the portability of mmh
-if systems don't support these standardized and widespread functions.
+if systems do not support these standardized and widespread functions.
 This compromise is made because mmh focuses on the future.
 .P
 I am not yet thirty years old and my C and Unix experience comprises
 only half a dozen years.
 Hence, I need to learn about the history in retrospective.
 .Fn profile .
 The location of the profile is no longer fixed to
 .Fn $HOME/.mh_profile
 but to
 .Fn $HOME/.mmh/profile .
-Having both, the file
+Having both the file
 .Fn $HOME/.mh_profile
 and the configuration directory
 .Fn $HOME/.mmh
 appeared to be inconsistent.
 The approach chosen for mmh is consistent, simple, and familiar to
 is built from
 .Fn uip/rmm.c .
 Some source files are used for multiple programs.
 For example
 .Fn uip/scansbr.c
-is used for both,
+is used for both
 .Pn scan
 and
 .Pn inc .
 In nmh, 49 tools were built from 76 source files.
 This is a ratio of 1.6 source files per program.
 .Pn grep
 would page without
 .Pn more
 just because both programs are part of the same code base.
 .P
-The clear separation on the surface \(en the toolchest approach \(en
+The clear separation on the surface \(en the tool chest approach \(en
 is violated on the level below.
 This violation is for the sake of time performance.
 On systems where
 .Fu fork()
 and

Mercurial > docs > master

comparison discussion.roff @ 173:4c7db172fb59