# HG changeset patch # User markus schnalke # Date 1337506819 -7200 # Node ID 49cf68506b5ddd47021cd324e65c5e404ff20ecf # Parent a446f89cc5d999b49a2c7c5726a34fc95c45b54c Spell checking. diff -r a446f89cc5d9 -r 49cf68506b5d ch01.roff --- a/ch01.roff Sat May 19 17:57:20 2012 +0200 +++ b/ch01.roff Sun May 20 11:40:19 2012 +0200 @@ -63,7 +63,7 @@ .U2 "Concepts .P -MH is a toolchest, modelled after the Unix toolchest. It consists of a +MH is a tool chest, modeled after the Unix tool chest. It consists of a set of tools, each covering a specific task of email handling, like composing a message, replying to a message, refiling a message to a different folder, listing the messages in a folder. @@ -97,14 +97,14 @@ adjust them to the user's personal preferences. Multiple versions of the same command with different default values can also be created very easily. -Form templates for new messages or for replies are easily changable, +Form templates for new messages or for replies are easily changeable, and output is adjustable with format files. Almost every part of the system can be adjusted to personal preference. .P -The system is well scriptable and extendable. +The system is well scriptable and extensible. New MH tools are built out of or on top of existing ones quickly. -Further more, MH encourages the user to taylor, extend and automate the system. -As the MH toolchest was modelled after the Unix toolchest, the +Further more, MH encourages the user to tailor, extend and automate the system. +As the MH tool chest was modeled after the Unix tool chest, the properties of the latter apply to the former as well. @@ -164,7 +164,7 @@ All this still was in times before POSIX and ANSI C. As large parts of the code stem from this time, today's nmh source code still contains many ancient parts. -BSD-specific code and constructs taylored for hardware of that time +BSD-specific code and constructs tailored for hardware of that time are frequent. .P Nmh started about a decade after the POSIX and ANSI C standards had been @@ -172,16 +172,16 @@ a part of the developers came from ``the old days''. The developer base became more diverse and thus resulted in code of different style. Programming practices from different decades merged in the project. -As several peers added code, the system became more a conclomeration -of single tools rather than a homogenic of-one-cast mail system. +As several peers added code, the system became more a conglomeration +of single tools rather than a homogeneous of-one-cast mail system. Still, the existing basic concepts held it together. They were mostly untouched throughout the years. .P -Despite the toolchest approach at the surface \(en a collection +Despite the tool chest approach at the surface \(en a collection of separate small programs \(en on the source code level it is much more interweaved. Several separate components were compiled into one program -for effiency reasons. +for efficiency reasons. This lead to intricate innards. Unfortunately, the clear separation on the outside appeared as being pretty interweaved inside. @@ -189,13 +189,13 @@ The advent of MIME rose the complexity of email by a magnitude. This is visible in nmh. The MIME-related parts are the most complex ones. It's also visible that MIME support had been added on top of the old MH core. -MH's toolchest style made this easily possible and encourages +MH's tool chest style made this easily possible and encourages such approaches, but unfortunately, it lead to duplicated functions and half-hearted implementation of the concepts. .P To provide backward-compatibility, it is a common understanding to not change the default settings. -In consequence, the user needs to activate modern features explicitely +In consequence, the user needs to activate modern features explicitly to be able to use them. This puts a burden on new users, because out-of-the-box nmh remains in the same ancient style. @@ -212,10 +212,10 @@ when there were no more than three commits to nmh in the previous nine months.. In December, when I announced my work on the nmh-workers mailing list, .[ -nmh-workers mmh announce december +nmh-workers mmh announce December .] the activity in nmh rose much. -Suddently the community started to move. +Suddenly, the community started to move. This movement was heavily pushed by Paul Vixie's ``edginess'' comment. .[ nmh-workers vixie edginess @@ -230,7 +230,7 @@ The project follows my personal considerations and preferences. By calling it a personal project, I don't need to justify my decisions, though, still I like to do. -This enabled me to follow my vision staightly and thus produce +This enabled me to follow my vision straightly and thus produce a result of greater pureness. This project model was inspired by the window manager \fIdwm\fP, which is Anselm Garbe's personal window manager \(en @@ -241,7 +241,7 @@ This should not happen to mmh. .P Mmh also stands for \fImodern mail handler\fP, and this is -the variant chosen to entitel this document. One main focus of the +the variant chosen to entitle this document. One main focus of the project was to modernize nmh. Another main goal is resembled in the name \fIminimized mail handler\fP: Drop any parts that don't add to the main task of mmh, being a conceptionally appealing MUA. @@ -257,22 +257,22 @@ .U2 "Motivation .P -MH is the most important of very few command line toolchest email systems. +MH is the most important of very few command line tool chest email systems. (There's also \fIim\fP by Tatsuya Kinoshita, which operates on an MH mail storage.) -Toolchests are powerful because they can be perfectly automated and -extended. Toolchests are good back-ends for various sorts of front-ends. +Tool chests are powerful because they can be perfectly automated and +extended. Tool chests are good back-ends for various sorts of front-ends. They allow multiple front-ends for different special needs -to be implemented quickly and withough internal knowledge on emailing. -Further more, toolchests are much better to maintain than large monolithic +to be implemented quickly and without internal knowledge on emailing. +Further more, tool chests are much better to maintain than large monolithic programs. -As there are few toolchests for emailing and MH-like ones are the most -popular amoung them, they should be developed further to keep their +As there are few tool chests for emailing and MH-like ones are the most +popular among them, they should be developed further to keep their conceptional elegance and unique scripting qualities available to users. mmh will create a modern and convenient entry point for new, interested users to MH-like systems. .P -The mmh project is motivated by deficites of nmh and +The mmh project is motivated by deficits of nmh and my wish for general changes, combined with the nmh community's reluctancy to change. .P @@ -293,7 +293,7 @@ compete with the large specialized projects that focus on only one of the components. The situation can be improved by concentrating the development power -on the most unique part of MH and letting the user pick his prefered +on the most unique part of MH and letting the user pick his preferred set of other mail components. Today's pre-packaged software components encourage this model. mmh is a way to go for this approach. @@ -326,9 +326,9 @@ He is at least capable of shell scripting and wants to improve his productivity by scripting the mail system. He naturally uses modern email features, like attachments, -non-ASCII text, and digital cryptrography. +non-ASCII text, and digital cryptography. He is able to setup email system components besides mmh, -and actually likes the choice to pick the ones he preferes. +and actually likes the choice to pick the ones he prefers. He has a reasonably modern system that complies to standards, like POSIX and ANSI C. .P @@ -336,7 +336,7 @@ shell session, but as well, he uses them to automate mail handling tasks. Likely, he runs his mail setup on a server machine, to which he connects via ssh. He might also have local mmh installations on his workstations, -but does rather not rely on graphical frontends. He definitely wants +but does rather not rely on graphical front-ends. He definitely wants to be flexible and thus be able to change his setup to suite his needs. .P The typical mmh user is a programmer himself. @@ -385,7 +385,7 @@ Time and space optimizations should to be replaced by clear and readable code. A uniform programming style should prevail. -.IP "Homogenity +.IP "Homogeneity The available concepts need to be expanded as far as possible. A small set of concepts should prevail thoroughly throughout the system. The whole system should appear to be of-one-style. diff -r a446f89cc5d9 -r 49cf68506b5d ch03.roff --- a/ch03.roff Sat May 19 17:57:20 2012 +0200 +++ b/ch03.roff Sun May 20 11:40:19 2012 +0200 @@ -6,23 +6,24 @@ .H1 "Removal of Code Relicts .P -The code base of mmh originates from the late 70s, had been extensively -worked on in the mid 80s, and had been partly reorganized and extended -in the 90s. Relicts of all those times had gathered in the code base. +The code base of mmh originates from the late Seventies, +had been extensively +worked on in the mid Eighties, and had been partly reorganized and extended +in the Nineties. Relicts of all those times had gathered in the code base. My goal was to remove any ancient code parts. One part of the task was converting obsolete code constructs to standard constructs, the other part was dropping obsolete functions. .P As I'm not even thirty years old and have no more than seven years of -Unix experience, I needed to learn about the history in retroperspective. -Older people likely have used those ancient constructs themself -and have suffered from their incompatiblities and have longed for +Unix experience, I needed to learn about the history in retrospective. +Older people likely have used those ancient constructs themselves +and have suffered from their incompatibilities and have longed for standardization. Unfortunately, I have only read that others had done so. This put me in a much more difficult positions when working on the old code. I needed to recherche what other would have known by heart from experience. All my programming experience comes from a time past ANSI C and past POSIX. Although I knew about the times before, I took the -current state implicitely for granted most of the time. +current state implicitly for granted most of the time. .P Being aware of these facts, I rather let people with more historic experience solve the @@ -156,7 +157,7 @@ .DE the resulting behavior is similar to .Pn mailx . -Appearently, +Apparently, .Pn prompter hadn't been touched lately. Otherwise it's hardly explainable why it still offered the switches @@ -171,7 +172,7 @@ .U2 "Vfork and Retry Loops .P -MH creates many processes, which is a concequence of the toolchest approach. +MH creates many processes, which is a consequence of the tool chest approach. In earlier times .Fu fork() had been an expensive system call, as the process's whole image needed @@ -194,7 +195,7 @@ in the cases when they can be exchanged. With .Fu vfork() -being more errorprone and hardly faster, it's preferable to simply +being more error-prone and hardly faster, it's preferable to simply use .Fu fork() instead. @@ -203,7 +204,7 @@ .Fu fork() is the probability of its success. Today on modern systems, the system call will succeed almost always. -In the 80s on heavy loaded systems, as they were common at +In the Eighties on heavy loaded systems, as they were common at universities, this had been different. Thus, many of the .Fu fork() calls were wrapped into loops to retry to fork several times in @@ -223,7 +224,7 @@ to go. There are excellent specialized MTAs, like Postfix; there are specialized MDAs, like Procmail; there are specialized MRAs, like Fetchmail. I believe it's best to use them instead of -providing the same function ourself. Doing something well requires to +providing the same function ourselves. Doing something well requires to focus on this particular aspect or a small set of aspects. The more it is possible to focus, the better the result in this particular area will be. The limiting resource in Free Software community development @@ -249,7 +250,7 @@ .P .Pn rcvtty was removed because its usecase of writing to the user's terminal -on receival of mail is hardly wanted today. If users like to be +on receiving of mail is hardly wanted today. If users like to be informed of new mail, then using the shell's .Ev MAILPATH variable or different (graphical) notifications are likely more @@ -290,9 +291,9 @@ .Pn msh was removed because the tool was in conflict with the original philosophy of MH. It provided an interactive shell to access the -features of MH. One major feature of MH is being a toolchest. +features of MH. One major feature of MH is being a tool chest. .Pn msh -wouldn't be just another shell, taylored to the needs of mail +wouldn't be just another shell, tailored to the needs of mail handling, but one large program to have the MH tools built in. It's main use was for accessing Bulletin Boards, which have seized to be popular. Removing @@ -311,7 +312,7 @@ .Fn draft and being located in the MH directory. When starting to compose another message -before the former one was sent, the user had been questioned wether to use, +before the former one was sent, the user had been questioned whether to use, refile or replace the old draft. Working on multiple drafts at the same time was impossible. One could only work on them in alteration by refiling the previous one to some directory and fetching some other one for reediting. @@ -413,8 +414,8 @@ is removed too, then the backup of the former message gets overwritten. Thus, the ability to restore removed messages does not only depend on the ``sweeping cron job'' but also on the removing of further messages. -This is undesireable, because the real mechanism is hidden from the user -and the concequences of further removals are not always obvious. +This is undesirable, because the real mechanism is hidden from the user +and the consequences of further removals are not always obvious. Further more, the backup files are scattered within the whole mail storage, instead of being collected at one place. .P @@ -425,14 +426,14 @@ was introduced, very early. It could be set to any command, which would care for the mail removal instead of taking the default action, described above. -Refiling the to-be-removed files to some wastebin folder was a common +Refiling the to-be-removed files to some garbage folder was a common example. Nmh's man page .Mp rmm(1) proposes .Cl "refile +d -to move messages to the wastebin and +to move messages to the garbage folder and .Cl "rm `mhpath +d all` -the empty the wastebin. +the empty the garbage folder. Managing the message removal this way is a sane approach. It keeps the removed messages in one place, makes it easy to remove the backup files, and, most important, enables the user to use the tools of MH @@ -447,7 +448,7 @@ .Pn mhpath to switch over from MH tools to Unix tools \(en MH can do it all itself. .P -This apporach matches perfect with the concepts of MH, thus making +This approach matches perfect with the concepts of MH, thus making it powerful. Hence, I made it the default. And even more, I also removed the old backup prefix approach, as it is clearly less powerful. Keeping unused alternative in the code is a bad choice as they likely @@ -588,8 +589,8 @@ .Pn mhl 's limited display facilities couldn't cope with the task any longer. Instead of extending these tools, new ones were written from scratch -and then added to the MH toolchest. Doing so is encouraged by the -toolchest approach. The new tools could be added without interfering +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. This is great. It allowed MH to be the first MUA to implement MIME. .P diff -r a446f89cc5d9 -r 49cf68506b5d dedication.roff --- a/dedication.roff Sat May 19 17:57:20 2012 +0200 +++ b/dedication.roff Sun May 20 11:40:19 2012 +0200 @@ -9,7 +9,7 @@ .ce 99 .ig The UNIX Programming Environment: - Instead, what makes it (the UNIX system) effective is an approch + Instead, what makes it (the UNIX system) effective is an approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from diff -r a446f89cc5d9 -r 49cf68506b5d preface.roff --- a/preface.roff Sat May 19 17:57:20 2012 +0200 +++ b/preface.roff Sun May 20 11:40:19 2012 +0200 @@ -2,7 +2,7 @@ .P MH is a set of mail handling tools with a common concept, similar to -the Unix toolchest, which is a set of file handling tools with a common +the Unix tool chest, which is a set of file handling tools with a common concept. nmh is the currently most popular implementation of an MH-like mail handling system. This thesis describes an experimental version of nmh, named \fImmh\fP. @@ -20,7 +20,7 @@ Such a change is not trivial, but in being convinced by the concepts and by having done similar transitions for file management and editing already, it was not too difficult neither. -In contrast, setting up nmh to a convenient state became a tendious task +In contrast, setting up nmh to a convenient state became a tedious task that took several months. .P Once having nmh arranged to a convenient state, I enjoyed using it @@ -146,7 +146,7 @@ kernighan ritchie c prog lang .] is the definitive guide to C. -Some book about system-level C programming is worthwile additional +Some book about system-level C programming is worthwhile additional literature. Rochkind and Curry have written such books. .[ rochkind advanced unix prog @@ -194,7 +194,7 @@ to any of the topics covered. It discusses Unix, email and system design on an advanced level. However, as knowledge of the fundamental concepts is the most valuable -information a user can aquire about some program or software system, +information a user can acquire about some program or software system, this document might be worth a read for non-developers as well. @@ -204,7 +204,7 @@ Meaning of `foo(1)'. RFCs. .P -This thesis is devided into XXX chapters, ... +This thesis is divided into XXX chapters, ... .P .I Chapter 1 introduces ...