# HG changeset patch # User markus schnalke # Date 1341933965 -7200 # Node ID 4c7db172fb5936217c65721de2814b51e274c51d # Parent 6800d594b2b723f24b819ed6c55c864b9b1bacda Various corrections and improvements. diff -r 6800d594b2b7 -r 4c7db172fb59 discussion.roff --- a/discussion.roff Tue Jul 10 17:20:21 2012 +0200 +++ b/discussion.roff Tue Jul 10 17:26:05 2012 +0200 @@ -21,8 +21,8 @@ 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. -Such a project won't be able to excel in all aspects. +Today, email is too complex to be fully covered by a single project. +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. @@ -43,7 +43,7 @@ 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, @@ -154,7 +154,7 @@ .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.'' @@ -274,7 +274,7 @@ .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. @@ -353,7 +353,7 @@ .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 @@ -448,14 +448,14 @@ 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. @@ -502,8 +502,7 @@ whatever was more appropriate. .P Having two similar tools for essentially the same task is redundant. -Usually, -users wouldn't distinguish between +Usually, users would not distinguish between .Pn show and .Pn mhshow @@ -606,7 +605,7 @@ 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 @@ -668,28 +667,28 @@ .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. -But giving the hash symbol as argument caused too many problems +and had the prefix character as argument. +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" @@ -933,7 +932,7 @@ 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 @@ -1834,7 +1833,7 @@ .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 @@ -1902,7 +1901,7 @@ .\" 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. @@ -1975,7 +1974,7 @@ 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. @@ -2014,7 +2013,7 @@ 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. @@ -2333,7 +2332,7 @@ .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 @@ -2580,7 +2579,8 @@ .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, @@ -2764,7 +2764,7 @@ 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, @@ -3115,7 +3115,7 @@ 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 */ @@ -3209,7 +3209,7 @@ 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 @@ -3222,7 +3222,7 @@ .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. @@ -3230,7 +3230,7 @@ .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 @@ -3468,7 +3468,7 @@ 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, @@ -3490,7 +3490,7 @@ .P In mmh, the wish to have .Pn mhmail -as as replacement for +as a replacement for .Pn mailx is considered obsolete. Mmh's @@ -3510,10 +3510,10 @@ .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 @@ -3567,7 +3567,7 @@ 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 @@ -3763,7 +3763,7 @@ .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 @@ -3821,7 +3821,7 @@ 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 . @@ -4045,7 +4045,7 @@ .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 diff -r 6800d594b2b7 -r 4c7db172fb59 intro.roff --- a/intro.roff Tue Jul 10 17:20:21 2012 +0200 +++ b/intro.roff Tue Jul 10 17:26:05 2012 +0200 @@ -228,7 +228,7 @@ then this compatibility surely is important. However, at the same time, new users have difficulties using nmh for modern emailing. -The small but mature community around nmh needs few change +The small but mature community around nmh needs little change as they have had their convenient setups for decades. .\" XXX Explain more @@ -383,7 +383,7 @@ Mmh should be stripped down to its core, which is the user agent (MUA). The feature set should be distilled to the indispensable ones, effectively removing corner cases. -Parts that don't add to the main task of being a conceptionally +Parts that do not add to the main task of being a conceptionally appealing MUA should be removed. This includes the mail submission and mail retrieval facilities. Choice should be reduced to the main options. diff -r 6800d594b2b7 -r 4c7db172fb59 preface.roff --- a/preface.roff Tue Jul 10 17:20:21 2012 +0200 +++ b/preface.roff Tue Jul 10 17:26:05 2012 +0200 @@ -44,10 +44,10 @@ .P Half a year later, starting in August 2010, I took one semester off to travel through Latin America. -During my time in Argentina, I wanted to work on Free Software. +During my time in Argentina, I wanted to work on free software. This brought me back to nmh. Richard Sandelman, an active nmh user, took care of the official basis. -Juan Granda, an Argentine Free Software developer, +Juan Granda, an Argentine free software developer, provided a computer with Internet connection. Thanks to them, I was able to work on nmh during my three-month stay in Santiago del Estero, Argentina. diff -r 6800d594b2b7 -r 4c7db172fb59 summary.roff --- a/summary.roff Tue Jul 10 17:20:21 2012 +0200 +++ b/summary.roff Tue Jul 10 17:26:05 2012 +0200 @@ -74,7 +74,7 @@ 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 toolchest could be reworked to operate on a generic back-end, +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?!