Next: Constraints on MH to use Hemlock’s Interface, Previous: The Mail Interface, Up: The Mail Interface [Contents][Index]
Hemlock provides an electronic mail handling facility via an interface to the public domain Rand MH Message Handling System. This chapter assumes that the user is familiar with the basic features and operation of MH, but it attempts to make allowances for beginners. Later sections of this chapter discuss setting up MH, profile components and special files for formatting outgoing mail headers, and backing up protected mail directories on a workstation. For more information on MH, see the Rand MH Message Handling System Tutorial and the Rand MH Message Handling System Manual.
The Hemlock interface to MH provides a means for generating header (scan) lines for messages and displaying these headers in a Headers buffer. This allows the user to operate on the current message as indicated by the position of the cursor in the Headers buffer. The user can read, reply to, forward, refile, or perform various other operations on the current message. A user typically generates a Headers buffer with the commands Message Headers or Incorporate and Read New Mail, and multiple such buffers may exist simultaneously.
Reading a message places its text in a Message buffer. In a manner similar to a Headers buffer, this allows the user to operate on that message. Most Headers buffer commands behave the same in a Message buffer. For example, the Reply to Message command has the same effect in both Headers mode and Message mode. It creates a Draft buffer and makes it the current buffer so that the user may type a reply to the current message.
The Send Message command originates outgoing mail. It generates a Draft buffer in which the user composes a mail message. Each Draft buffer has an associated pathname, so the user can save the buffer to a file as necessary. Invoking Send Message in a Headers or Message buffer associates the Draft buffer with a Message buffer. This allows the user to easily refer to the message being replied to with the command Goto Message Buffer. After the user composes a draft message, he can deliver the message by invoking the Deliver Message command in the Draft buffer (which deletes both the this buffer and any associated Message buffer), or he can delay this action. Invoking Deliver Message when not in a Draft buffer causes it to prompt for a draft message ID, allowing previously composed and saved messages to be delivered (even across distinct Lisp invocations).
The Hemlock mail system provides a mechanism for virtual message deletion. That is, the Delete Message command does not immediately delete a message but merely flags the message for future deletion. This allows the user to undelete the messages with the Undelete Message command. The Expunge Messages command actually removes messages flagged for deletion. After expunging a deleted message, Undelete Messages can no longer retrieve it. Commands that read messages by sequencing through a Headers buffer typically ignore those marked for deletion, which makes for more fluid reading if a first pass has been made to delete uninteresting messages.
After handling messages in a Headers buffer, there may be messages flagged for deletion and possibly multiple Message buffers lying around. There is a variety of commands that help terminate a mail session. Expunge Messages will flush the messages to be deleted, leaving the buffer in an updated state. Delete Headers Buffer and Message Buffers will delete the Headers buffer and its corresponding Message buffers. Quit Headers is a combination of these two commands in that it first expunges messages and then deletes all the appropriate buffers.
One does not have to operate only on messages represented in a Headers buffer. This is merely the nominal mode of interaction. There are commands that prompt for a folder, an MH message specification (for example, "1 3 6 last", "1-3 5 6", "all", "unseen"), and possibly a pick expression. Pick expressions allow messages to be selected based on header field pattern matching, body text searching, and date comparisons; these can be specified using either a Unix shell-like/switch notation or a Lisp syntax, according to one’s preference. See section scanning for more details.
A mail-drop is a file where a Unix-based mail system stores all messages a user receives. The user’s mail handling program then fetches these from the mail-drop, allowing the user to operate on them. Traditionally one locates his mail-drop and mail directory on a mainframe machine because the information on mainframes is backed up on magnetic tape at least once per day. Since Hemlock only runs under CMU COMMON LISP on workstations, and one’s mail directory is not usually world writable, it is not possible to adhere to a standard arrangement. Since MH provides for a remote mail-drop, and CMU’s Remote File System has a feature allowing authentication across a local area network, one can use Hemlock to fetch his mail from a mainframe mail-drop (where it is backed up before Hemlock grabs it) and store it on his workstation. Reading mail on a workstation is often much faster and more comfortable because typically it is a single user machine. Section backing-up describes how to back up one’s mail directory from a workstation to a mainframe.
Next: Constraints on MH to use Hemlock’s Interface, Previous: The Mail Interface, Up: The Mail Interface [Contents][Index]