docs/master: ch03.roff comparison

comparison ch03.roff @ 51:49cf68506b5d

Spell checking.

author	markus schnalke <meillo@marmaro.de>
date	Sun, 20 May 2012 11:40:19 +0200
parents	d3a02f5e63b3
children	814c33b96d89

comparison

equal deleted inserted replaced

-:a446f89cc5d9
+:49cf68506b5d
 .P
 bar
 .H1 "Removal of Code Relicts
 .P
-The code base of mmh originates from the late 70s, had been extensively
+The code base of mmh originates from the late Seventies,
-worked on in the mid 80s, and had been partly reorganized and extended
+had been extensively
-in the 90s. Relicts of all those times had gathered in the code base.
+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.
+Unix experience, I needed to learn about the history in retrospective.
-Older people likely have used those ancient constructs themself
+Older people likely have used those ancient constructs themselves
-and have suffered from their incompatiblities and have longed for
+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
 task of converting the ancient code constructs to standardized ones.
 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
 .DS
 comp \-editor prompter
 .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
 .Sn \-erase \fUchr\fP
 and
 with the standard tool
 .Pn stty .
 .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
 to be duplicated. One common case is replacing the image with
 .Fu exec()
 almost as fast as
 .Fu vfork()
 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.
 .P
 Related to the costs of
 .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
 short intervals, in case of previous failure.
 In mmh, the program aborts at once if the fork failed.
 In fundamental difference, I believe that mmh should be a MUA but
 nothing more. I believe that all-in-one mail systems are not the way
 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
 usually is human power. If the low development power is even parted
 into multiple development areas, it will hardly be possible to
 files.
 The tool might be useful, but it should not be shipped with mmh.
 .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
 appealing. Writing directly to other terminals is hardly ever wanted
 today. If though one wants to have it this way, the standard tool
 there's no need to check for new mail before incorporating it.
 .P
 .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
 .Pn msh ,
 together with the truly obsolete programs
 .P
 Historically, MH provided exactly one draft message, named
 .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.
 This manual draft management needed to be done each time the user wanted
 to switch between editing one draft to editing another.
 .Fn 6
 \(en, if that one
 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
+This is undesirable, because the real mechanism is hidden from the user
-and the concequences of further removals are not always obvious.
+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
 To improve the situation, the profile entry
 .Pe rmmproc
 (previously named
 .Pe Delete-Prog )
 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
 itself to operate on the removed messages. One can
 .Pn scan
 There's no more
 need to use
 .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
 gather bugs, by not being constantly tested. Also, the increased code
 size and more conditions crease the maintenance costs. By strictly
 .Pn show 's
 simple approach and
 .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
+and then added to the MH tool chest. Doing so is encouraged by the
-toolchest approach. The new tools could be added without interfering
+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
 The new MIME features were added in form of the single program
 .Pn mhn .

Mercurial > docs > master

comparison ch03.roff @ 51:49cf68506b5d