diff --git a/library/lafite/docs/README b/library/lafite/docs/README new file mode 100644 index 00000000..88735616 --- /dev/null +++ b/library/lafite/docs/README @@ -0,0 +1,10 @@ +Lafite README + +the end-user documentation for Lafite in a PDF is on Google Drive + +https://drive.google.com/drive/folders/1Zb2IudbnlzfEK5YzTcEr7k2liclFUquE?usp=sharing + +Here (in the GitHub Interlisp/medley repo) +you will find the .TEdit sources that can be used to produce the documentation using ths utility HCFILES on the file MEDLEY-UTILS in the "internal" folder. + +For Lafite there are two folders, one with the (latest) documentation and one with release notes. diff --git a/library/lafite/docs/release-notes/ChangesLyric.tedit b/library/lafite/docs/release-notes/ChangesLyric.tedit new file mode 100644 index 00000000..211cbcf2 Binary files /dev/null and b/library/lafite/docs/release-notes/ChangesLyric.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITE-Delta-1-90.tedit b/library/lafite/docs/release-notes/LAFITE-Delta-1-90.tedit new file mode 100644 index 00000000..c89bc9d6 Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITE-Delta-1-90.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITE-Delta-11-89.tedit b/library/lafite/docs/release-notes/LAFITE-Delta-11-89.tedit new file mode 100644 index 00000000..cf45d7b3 Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITE-Delta-11-89.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITE-Delta-2-1-89.tedit b/library/lafite/docs/release-notes/LAFITE-Delta-2-1-89.tedit new file mode 100644 index 00000000..fdc01ac9 Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITE-Delta-2-1-89.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITE-Delta-2-23-89.tedit b/library/lafite/docs/release-notes/LAFITE-Delta-2-23-89.tedit new file mode 100644 index 00000000..d547f6d4 Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITE-Delta-2-23-89.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITE-Delta-5-89.tedit b/library/lafite/docs/release-notes/LAFITE-Delta-5-89.tedit new file mode 100644 index 00000000..3302a220 Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITE-Delta-5-89.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITE-Delta-8-89.tedit b/library/lafite/docs/release-notes/LAFITE-Delta-8-89.tedit new file mode 100644 index 00000000..1ceaaeff Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITE-Delta-8-89.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITE-Delta-9-88.tedit b/library/lafite/docs/release-notes/LAFITE-Delta-9-88.tedit new file mode 100644 index 00000000..9a79e387 Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITE-Delta-9-88.tedit differ diff --git a/library/lafite/docs/release-notes/LAFITEDELTA.TED b/library/lafite/docs/release-notes/LAFITEDELTA.TED new file mode 100644 index 00000000..b4fbb688 Binary files /dev/null and b/library/lafite/docs/release-notes/LAFITEDELTA.TED differ diff --git a/library/lafite/docs/release-notes/Lafite-85.TEdit b/library/lafite/docs/release-notes/Lafite-85.TEdit new file mode 100644 index 00000000..36349da8 --- /dev/null +++ b/library/lafite/docs/release-notes/Lafite-85.TEdit @@ -0,0 +1,448 @@ +Lafite The Interlisp Mail System Documentation: {Eris}Library>Lafite.Press Program: {Eris}Library>Lafite.Dcom Revised: February 22, 1984 by Bill van Melle General comments Lafite is the Interlisp system for reading and sending mail. Lafite retrieves inbound mail from the user's inboxes on one or more mail servers. Mail is retrieved into one or more mail folders, which can be any Interlisp-accessible file. One can open a browser on a mail folder, which allows the folder's contents to be displayed, deleted, moved into other folders, hardcopied, etc. Messages can be composed using the standard Interlisp text editor and all its facilities, then sent to other users. Lafite permits communication with various sorts of mail servers. Currently implemented are interfaces to the Grapevine mail system and the NS mail system. Mail systems are notorious for inspiring lengthy wish lists for new functionality or user interface embellishments. Feel free to send your suggestions to LafiteSupport (using Lafite's ``Lafite Report'' form, described below). Compatibility with Laurel Previous users of the Laurel mail program will find Lafite to have a similar user interface. Some of the ways in which it differs from Laurel are the following: Laurel can only access mail folders on the local disk; Lafite can access folders on remote file servers. Thus, it is not necessary to transfer mail folders back and forth between your local disk and your file servers. Laurel can only ``browse'' one mail folder at a time; Lafite can have several mail folders ``opened'' at the same time. Utilizing the Interlisp window system, you can view the table of contents of many mail folders and refer to messages in them independently. You may have multiple windows displaying messages and multiple windows for sending messages and you may move text freely among them. Lafite can read mail files written by the Laurel and Hardy mail programs; the files it writes are in Laurel format. Loading Lafite Lafite consists of two parts: a generic part that manages browsers, mail folders and message composition; and a protocol-specific part that manages communication between Lafite and the remote mail system. You have to load both parts. The first is the file LAFITE.DCOM, plus the files that it automatically loads. The second depends on your network environment. For sites that use the Xerox NS Mail system, you should load the file NSMAIL.DCOM. For Grapevine sites, load the file MAILCLIENT.DCOM. If your site has a choice of mail server types, you can load all the relevant protocol files and then choose among them by setting the mode (see Lafite Modes, below). Lafite operation When Lafite is loaded, it can be started by calling (LAFITE 'ON MAILFOLDER). Lafite will attempt to establish the user's mail server identity, read stored user data from the file LAFITE.PROFILE (if it exists) and bring up the Lafite Status window. It will then establish a browser for the file MAILFOLDER, creating an empty mail folder of that name if one does not exist. If MAILFOLDER is not supplied then ACTIVE.MAIL will be used (see DEFAULTMAILFOLDERNAME below). If MAILFOLDER is supplied but is the atom NIL, then no mail folder is opened but you are free to send mail and open any mail folder at a later time. Mail files must reside on randomly-accessible devices. In the current Interlisp environment, this means they must reside on {DSK}, {FLOPPY}, or a file server that supports the Leaf protocol. There are three major types of windows used by Lafite: the Status Window; Browser Windows, which are views on particular mail folders; and Message Composition Windows. Each type of window has its own fixed menu of commands. In general, while a command is ``in progress'', the menu item that invoked it is greyed out. Commands may be selected with the LEFT or MIDDLE mouse buttons; in some cases, the MIDDLE button provides some sort of special treatment, described in the documentation of such commands. The Lafite Status Window The Lafite Status window contains a small, fixed menu and a region for Lafite status information. While Lafite is in operation, it runs a background processLAFITEMAILWATCHthat polls the user's inboxes periodically and reports in the status region if there is new mail. Clicking in the status region causes the background process to wake up and report status immediately, instead of waiting its normal interval. The commands in this window's menu are as follows: Browse  pops up a menu of the mail folders that Lafite is aware that you have. Selecting `Another Folder' prompts you for a folder name in the prompt window. After a folder is selected, a browser window onto that mail folder is opened. Selecting the Browse command with the MIDDLE button brings up a menu of Browse-related commands. In addition to simple Browse there are these commands: Browse Laurel Folder  Browses a file that was produced by the Laurel mail reader version 6.1 or later. Laurel 6.1 files are almost the same as Lafite files, but contain some line-formatting information that is stripped out by this command. After you have applied this command once to a file, you can subsequently browse the file with the normal Browse command (unless you use Laurel on it again, of course). Important Note: this command is not intended for repeated use, but simply to make mail files built by Laurel more pleasing to browse. This command has the side effect of destroying any Tedit formatted messages, so should be used with care. Forget Folder  Removes a folder from the list of known mail folders. Forget Message Form  Removes a message form from the list of known message forms (see Save Form command). Send Mail  brings up an Interlisp text editor window on a message form. The form is a canonical ``empty message'' if Send Mail is selected with the LEFT button. If Send Mail is selected with the MIDDLE button, a menu is presented with the following choices: Standard Formprovides an empty message template (same as using the LEFT button). Lisp Reportprovides a message template to report an Interlisp bug or make a suggestion. Lafite Reportprovides a message template similar to Lisp Report but sent to Lafite maintainers. Saved Formprompts for a form name, which can be any text file, or a form created by the Save Form command (below). Also in the menu are any names of known user-defined message forms created by the Save Form command. Each message form runs in its own process, so you can have several in progress at once. When you have finished composing the message, click Deliver in the message's menu. Quit  Stops Lafite and closes all browser windows. If any of the associated mail folders need updating, prompts with a menu asking what degree of updating should be performed (see Update command). It also saves the names of known mail folders and form files on the file LAFITE.PROFILE so that this information will be available when you next run Lafite. You may achieve the same result under program control by calling (LAFITE 'OFF), rather than buttoning this menu item. Most users find that they never invoke `Quit', but rather keep Lafite always active in the background. Selecting the Quit command with the MIDDLE button brings up a menu of status changing commands. This menu includes items for changing Lafite's mode (see Lafite Mode), and the command Restart, which is equivalent to (LAFITE 'OFF) followed by (LAFITE 'ON NIL). Browser Windows A Browser window is a view onto a mail folder. The main part of the window displays the table of contents, a one-line summary of each message. This window is scrollable in both dimensions. Above the table of contents is a horizontal menu containing commands specific to the mail folder associated with the browser window. Above the menu is a prompt window, in which various status information related to the browser is printed, and where some information is prompted for. Browser comands operate on the currently selected set of messages. A selected message is indicated by a black triangle to the left of its message number. A message can be selected by clicking anywhere inside its summary line. The type of selection depends on which button is used: left button  selects just this single message, deselecting any other selected message. middle button  adds a message to the current selection. right button  extends the selection up or down. Deleted messages are not included in this extension unless the control key (CTRL) is down. shift key (SHIFT) and any button  removes this message from the current selection. Laurel users note: messages can be selected by clicking anywhere within the summary line (except for the mark area, see below), unlike in Laurel, where you must select at the left end. The commands in the browser menu are as follows: Display  displays the selected message. If the selected message is already displayed, the selection is advanced to the next undeleted message, and this message is displayed. If there is more than one message selected, buttoning Display cycles through the messages. If you select Display with the LEFT button, the message is displayed in the primary message display window for the browser, replacing any previously displayed message. If you select Display with the MIDDLE button, the message is displayed in a newly created window, for which you will be prompted. Using the MIDDLE button you can make multiple windows containing messages for further reference (e.g., to use in composing your own message). Delete  deletes the selected messages. A deleted message is indicated by a black line through its summary line. The message is not actually removed from the mail folder until you Expunge (see Update, below). Undelete  undeletes the selected messages. Answer  constructs a Message Composition Window containing an answer template for the current message. After you deliver the answer, an ``a'' will appear in the browser window as the message's mark. Forward  similar to 'Answer' but the message form is a forward template for the currently selected messages. After you deliver the forwarded the messages, an ``f'' will appear as the message's mark. Hardcopy  prints the selected messages on your local printing device. When the hardcopy is complete, the message's mark is changed to ``h'' if the message didn't already have a more interesting mark. Messages can be marked for hardcopy, but the actual printing deferred until later; see description of LAFITEHARDCOPYBATCHFLG. Currently, one should exercise care in hardcopying large sets of messages, as Lafite makes no attempt to perform the hardcopying in smaller pieces; too large a body of messages can make printers unhappy, or exhaust local disk space in the process. Move To  pops up a menu of known mail folders and moves the selected messages to the chosen folder. A new mail folder can be created by selecting `Another Folder' and typing in the mail folder name in the prompt window. You will then be asked to confirm the move. When the move is successful, the messages are marked deleted in the source browser window, and given the ``m'' mark. The name of the mail folder you most recently moved messages to appears in the title bar of the browser window as the ``Default 'Move To':'' folder. You can ``accelerate'' subsequent Move operations by selecting the 'Move To' command with the MIDDLE button. This will perform the move to the Default 'Move To' folder without bringing up a menu. Update  The changes that you make to your mail folder (deletions, changes of message marks, etc) are not actually transmitted to the physical mail file until you perform the Update command. There are two subcommand choices for Update: Write out Changes Only  makes the browser and the mail file completely consistent with one another: if you were at this point to logout from Lisp, run Lafite in another incarnation of Lisp, and browse the same mail folder, you would get a browser that was in exactly the same state, deleted messages and all. This command involves writing out to your mail file and its table of contents the information about what has changed: new marks, deletions, newly parsed messages. Expunge Deleted Messages  in addition to making the browser and the mail file completely consistent with one another, this command compacts your physical mail file so as to remove all messages marked deleted. Which to choose? You eventually want to Expunge, so as to reduce the amount of file space your mail requires, but Expunge is not always fast. Expunge requires rewriting your mail file starting at the first deleted message, so is somehow ``proportional'' to the number of undeleted messages beyond that point. Write out Changes Only is proportional to the number of changes, and is thus usually faster than Expunge, except when the changes consist primarily of a string of deleted messages at the end of the folder. If you Close or Shrink a Browser window that has had changes to it, you are prompted with a menu offering to Write out Changes, Expunge, or make no change before the window is closed/shrunk. If you have deferred hardcopy, the Update menu also includes a choice Do Hardcopy Only if you want to print out your messages but not actually update the file. Get Mail  brings new mail into the folder that this browser is viewing. Changing the Message Mark Each message in a mail folder has a ``message mark'', which is an additional tidbit of information about the message displayed in the summary line in the browser. Messages originally come in with the mark ``?'', meaning they are unexamined. Some Lafite commands change the mark automatically. For example, displaying a message changes its mark from ``?'' to a blank; answering a message changes its mark to ``a''. You can change the mark directly by selecting with the mouse in the narrow area immediately to the left of the message number, where the mark is printed. Simply click in the mark position, and type the new mark (a single character). The Table of Contents To speed the browse operation, Lafite maintains, for each mail folder you browse, a ``table of contents'' file, which contains all the information displayed in the browser window. This file is named by concatenating the name of the mail file with ``-LAFITE-TOC''. This file is completely redundant, in that if it doesn't exist, Lafite simply recomputes it by parsing the entire mail file. Lafite has some rudimentary checks to guarantee the consistency of the contents file with the mail file it describes; Lafite deletes and recomputes the contents if it suspects that the table of contents file is out of date. Message Composition Windows On top of the text editor window is a horizontal menu for telling Lafite what to do with the message being created in the text editor window. When you have transformed the text to the desired message, select one of the following menu items: Deliver  sends your message. This process happens in background, so you can proceed with anything else you desire while delivery proceeds. If successful, the window closes and an entry is made in your outbox (see below). If the delivery fails, for any of a variety of reasons (e.g. bad address fields, the mail server timed out) which will be displayed in the prompt window, the message is redisplayed and you are back in the text editor to re-edit and then resend the message. During the delivery process, the menu atop the message window changes into a single item, Abort; if you click this item, the delivery is aborted, and you are returned to editing your message. Save Form  asks you for a file name on which to save this message for later use. This is the way to save a message form for later repetitive use. It does not send it. If no extension is given for the file name, it defaults to the value of LAFITEFORM.EXT (initially LAFITE-FORM). Of course, you can always bring up the text editor command menu by MIDDLE buttoning the title bar of the editor window. You can then do any text editor command. If you select `Quit' you will immmediately leave the text editor, bypassing the above commands. You can also simply close a window using the normal window command menu if you decide you don't want to do anything with a message you started composing. When editing message forms, fields that should be filled in are enclosed in ``>>'' and ``<<''; e.g., >>Recipients<<, >>Subject<<. To make it easier to fill these in, the first field is highlighted in delete mode. Each successive field can be reached by typing the middle-blank key on the keyboard (or OPEN on the Dandelion keyboard, or whichever key you have assigned the TEdit ``Next'' syntax to). See the TEdit documentation for details. In a saved form, if you insert a field ``>>Self<<'', it will be automatically filled with the name of the currently logged in user when retrieved into a message composition window. This facilitates making forms that many different people can use. Of course, if you edit an already saved form containing ``>>Self<<'' in a message composition window, you will have to perform the inverse, replacing your name with ``>>Self<<'', before saving it away again. After a message is succesfully delivered, it is entered into your outbox, a window attached to the bottom of your status window. This window contains a one line description of each of the most recent n messages you have sent, where n is the value of the variable LAFITEOUTBOXSIZE, initially 2. The outbox is treated as a menuselecting a line in it brings up the corresponding message for further editing and delivery. The outbox can be independently closed, if you are no longer interested in the messages displayed therein and want to free up the resources that they are tying down. Format of Message Headers The header of a message contains a number of fields, each on a separate line, followed by a blank line to separate the header from the message body. Each header line consists of a field name followed by a colon, then the contents of the field. Messages standardly have ``To:'' and ``cc:'' fields consisting of one or more recipient names, separated by commas (and spaces if desired). Lafite automatically supplies a ``From'' field containing your name. If you want the message to appear to be ``from'' someone else (e.g., if you are sending the message from someone else's logged in Lafite), or from more than one user, you can supply your own ``From'' field. In this case, Lafite will supply a ``Sender'' field to show who actually sent the message. Sending Formatted Messages You have available to you the full power of TEdit when you are composing a message. This means you can change fonts, format paragraphs, and insert ``image objects''. If you try to deliver such a formatted message, Lafite will ask if you want to retain the formatting information, putting up a menu with these choices: Send Formatted Message  retains all the formatting information. Note that only Lafite users can read formatted messages; all other mail readers will see the plain text of the message. Even if all of the recipients are Lafite users, keep in mind that retaining the formatting information means in particular retaining the fonts you used in composing the message; not everyone likes to read mail in the font you chose, so if the only ``formatting'' is a nonstandard font that isn't important to the appearance of the message, do not make this choice. This choice is made automatically if the message contains image objects, as there is no way to send the images without the formatting. Send Plain Text  sends only the text of the message. The message will appear to the recipient in whatever font her mail reader standardly uses, and all paragraph formatting (centering, justification, special tabstops) will vanish. Abort  does not send the message, but returns to the message editor to allow you to continue editing the message. Lafite Modes Lafite is capable of sending and retrieving mail via different protocols. At any one time, however, it only operates with a single protocol set, which is considered its current ``mode''. The currently implemented modes are GV (Grapevine) and NS. The easiest way to change the mode is to use the MIDDLE-button menu under Quit. Lafite's mode can also be changed programmatically with the function LAFITEMODE: (LAFITEMODE MODE) Returns the current mode, a litatom. In addition, if MODE is non-NIL, changes Lafite's mode to be MODE. When Lafite is first turned on, it chooses its mode as follows: If there is only one mode supported (i.e., only the files supporting one protocol have been loaded), it chooses that mode; otherwise, if LAFITEMODEDEFAULT is non-NIL, it chooses that mode; otherwise, the user must set the mode manually. The current mode is displayed in the status window if LAFITESHOWMODEFLG is true and more than one set of mail protocol implementations has been loaded. You can freely intermix mail of the various modes in one folder, but the current implementation is not very clever about it. For example, the Answer command always treats the selected message as if it were one in the current mode. So if you try to answer a Grapevine message while in NS mode, some confusion may result. Grapevine The Grapevine implementation of mail protocols is obtained by loading the library file MAILCLIENT.DCOM. Grapevine addresses are of the form ``name.registry'', e.g., ``Carstairs.pa''. If you omit the registry, it is defaulted to the value of DEFAULTREGISTRY. Arpanet recipients are of the form ``name@host''. In addition, the following forms of address are recognized, where ``actual address'' must be a valid Grapevine or Arpanet address: Human sensible name actual address (random comments) "Comments, including parentheses and commas" If you address a message to a public distribution list (a Grapevine name ending in the character ``^'') and have not included a Reply-to field, Lafite will prompt you to supply one. Your choices are to include a Reply-to: self field, so that answers to this message will be sent only to you; a Reply-to: other field (you get to fill it in yourself), or no Reply-to: field at all. It is important to have a Reply-to field in messages sent to distribution lists, so that casual users will not inadvertantly reply to the entire distribution list when a reply to you only was intended. Please be careful in using public distribution lists. Keep in mind that your one message will be received by many peopleis what you have to say important enough to be worth taking their time? There are certain organizational distribution lists, e.g., AllPA^.pa, or ISL^.pa, that you should definitely avoid sending casual messages to, as they are large and their members are not voluntary. Other distribution lists are really ``interest lists'' whose members have voluntarily consented to receive messages in the general category of movies, concert announcements, humorous anecdotes, or whatever. Messages to these lists are less constrained, but you should still take a moment to think about whether your message is appropriate. I highly recommend that all electronic mail users read Chapter 6 of the Laurel manual, ``Message system mores''. Shortcomings as of this writing: Private distribution lists are not yet supported. And the Answer command does not preserve the entire text of the variant forms listed above, only the ``actual address''. NS Mail The NS implementation of mail protocols is obtained by loading the library file NSMAIL.DCOM. NS addresses are of the form ``name:domain:organization'', e.g., ``Carstairs:PARC:Xerox''. If you omit the domain and/or organization, they are defaulted to your own domain and organization. NS mail does not support the many variant forms of address that Grapevine does, because the header is not actually sent as text, but as a structured set of formally named recipients. Some users of the NS Mail system send messages in a format that Lisp does not understand. The current Lafite implementation leaves such messages in your inbox to be retrieved by other means; all that you see back from GetMail is a header and a note that there was an attachment that Lafite couldn't read. Changing the Lafite UserLafite customization (LAFITE ON/OFF MAILFOLDER . OPTIONS) Used for starting and stopping Lafite with an optional mail folder. If ON/OFF is the atom ON then Lafite will start processing using MAILFOLDER. If MAILFOLDER is not supplied then Lafite will use your ACTIVE.MAIL mail folder (actually, the value of DEFAULTMAILFOLDERNAME). If MAILFOLDER is supplied but is the atom NIL then no browser will be created but you can send messages and start browsing mail files later using the 'Browse' menu item. If ON/OFF is the atom OFF then Lafite will close all mail folders, expunging all messages marked for deletion; close all windows associated with Lafite; and remove the mail watching process from the active process list. This is the same as invoking 'Quit' in the Lafite Status Window. The third and subsequent arguments are options. The only one currently recognized is the atom SHRINK, which instructs Lafite to immediately shrink the browser window brought up on MAILFOLDER. In this case, if MAILFOLDER is (explicitly) NIL, it still defaults to DEFAULTMAILFOLDERNAME, since SHRINK makes no sense otherwise. Lafite uses its own host and directory names for mail folders, LAFITE.PROFILE, etc., rather than the current connected directory because you may want to keep your mail folders someplace special (e.g., the local disk or your login directory), and the connected directory can change. The global variable LAFITEDEFAULTHOST&DIR is provided to tell Lafite where you generally keep your mail. LAFITEDEFAULTHOST&DIR should be atomic, in the same form as LOGINHOST/DIR (e.g. {PHYLUM}). If LAFITEDEFAULTHOST&DIR is NIL, then the value of LOGINHOST/DIR is usedi.e., your login host and directory. If you are running in a Lisp in which some previous user has been using Lafite, you need to take some action to get Lafite to work on your mail files and in your name. When you change your user identity by calling (LOGIN) to log in as yourself, Lafite notices that the current user has changed, and attempts to authenticate the new user. However, Lafite still doesn't know how you want your Lafite customized; in particular, Lafite notices the value of LAFITEDEFAULTHOST&DIR, and loads your profile of known folders only when Lafite is first started. Thus to change the identity of the Lafite user, you should follow the following procedure: 1) Turn Lafite off, by clicking Quit in the status window, or calling (LAFITE 'OFF). 2) Log in as the new user by calling (LOGIN). 3) Set LAFITEDEFAULTHOST&DIR and/or LOGINHOST/DIR as appropriate, and any other personal variables that affect Lafite that matter to you. A typical way to do this step is to call (GREET) to get your personal initialization loaded. 4) Restart Lafite by calling (LAFITE 'ON). When things go wrong... Lafite tries fairly hard not to break, but it is running in a very open environment, where users are free to interrupt arbitrary processes, network servers come and go, etc. As of this writing, the following are some abnormal states of note: Mail file does not parse. This shows up when you browse a folder, Lafite starts parsing the folder, and encounters an error in the file, typically an incorrect message length. Lafite prints a message to this effect in the browser window and aborts the browse. The information Lafite prints includes the header of the last message parsed, and a byte pointer where the problem was encountered. The byte pointer is such that if you truncated the file to that pointer position, the mail file would be valid. Solution: scavenge the mail file. The Library package MAILSCAVENGE contains a mail file scavenger. The Laurel MailFileScavenger program also works on Lafite files, as does the Hardy scavenger (I think). The most common way to get a mail file into an inconsistent state is to abort a MoveTo or Update command somewhere in the middle (either manually, or because a remote server crashed). In the case of MoveTo, the problem is usually that the last message in the file is ``too short'', since it never was completely written. If the first operation you perform on the destination file after the crash is to browse it, Lafite will (usually) detect this situation and let you browse the file anyway, with a warning that the last message is truncated. Updating the file will then correct the length of the last message. Thus, in this case, you will not need a scavenger. If you neglect to browse the destination file before moving additional messages to it, however, you will need to scavenge. Table of contents inconsistent with mail file. In theory, this should never happen; however, practice shows that it does. Lafite breaks with a message to this effect when it tries to operate on a message that isn't where it thought it was in the file. The appropriate action to take is to close the browser, selecting Don't Update, delete the table of contents file (the file with -LAFITE-TOC appended to the name), and then browse the file again. If this is not successful, you may need to scavenge the file. If you had made many changes to the browser (deletions, for example) that you would rather not lose, you can try selecting Write out Changes Only when you close the browser; this may succeed if the inconsistencies in the table of contents did not intersect with your changes. Slow file server. If your mail files live on a remote file server that is particularly unresponsive, it may happen that the mail server connection over which new mail is being retrieved times out before the file server acknowledges receipt of the messages. The usual consequence of this is that your inbox is not flushed, so your new mail is in two places: your inbox, awaiting retrieval, and your mail file, to which it was just retrieved. A less common occurrence is that the mail server times out partway through the retrieval process, resulting in a Lisp break. You can ^ out of the break to return to the state before the GetMail started. If this is often a problem for you, you may want to adopt the following idiom, which several people have found useful in maintaining the flexibility of remote mail files while utilizing the speed and reliability of the local disk. Keep most of your mail files on the remote server, as usual, but keep your ``active'' mail file, the one to which you standardly retrieve mail, on your local disk. Retrieve mail to this file, and dispatch from there to your remote files (using MoveTo) some or all of the messages you wish to keep. Mail files on {DSK} have very predictable performance during GetMail, which is good for both you and the mail server. Files on {DSK} are also less subject to other vagaries of remote servers (e.g., sudden crashes) that sometimes cause problems with mail files. And if you tend to delete much of your incoming mail after reading it once, you will find it much faster to keep your active mail on {DSK}, even if your remote server isn't flaky. You can also choose to keep most or all of your mail files on {DSK}, backing them up to a file server periodically. The LispUsers package COPYFILES is helpful for doing the backup automatically. Lafite Profile Variables Below are the global variables that control Lafite's behavior. DEFAULTREGISTRY The name of your local registry, used if your login name does not include a registry. This is normally set in the local site-specific INIT.LISP file. LAFITEDEFAULTHOST&DIR The directory on which Lafite looks for LAFITE.PROFILE and all mail folders and message forms you access if you don't supply an explicit directory. See ``Changing the Lafite User'' above. DEFAULTMAILFOLDERNAME If no mail folder is supplied to the function LAFITE, i.e., you call (LAFITE 'ON), then the value of this variable is used. Initially, ACTIVE.MAIL. LAFITEMAIL.EXT The default extension for names of mail folders. Initially, MAIL. LAFITETOC.EXT The string appended to the name of a mail folder to produce the name of its table of contents file. Initially, -LAFITE-TOC. LAFITEFORM.EXT The default extension for names of user-defined form files. Initially, LAFITE-FORM. LAFITEFORMDIRECTORIES A search path for Lafite forms, initially NIL. When you choose the Saved Form command underneath Send Mail, the form name that you enter is first searched for on your default directory (LAFITEDEFAULTHOST&DIR), and if not found there, Lafite searches the directories in the list LAFITEFORMDIRECTORIES. LAFITEFORMDIRECTORIES is typically set to a list of one or more public directories on which generally useful forms have been collected. MAILWATCHWAITTIME The number of minutes between polling for new mail from your mail servers. Initially set to 5. LAFITEFLUSHMAILFLG If NIL, Lafite won't flush your inbox when retrieving new mail, so the mail will still be there when you invoke Get Mail again. Initially, T. LAFITENEWPAGEFLG If T, then the Hardcopy command will start each message on a new page. Otherwise it will separate each message by a line of dashes. Intially, T. LAFITEHARDCOPYBATCHFLG If you often request hardcopy of single messages, one at a time, you may notice some disadvantages: short messages sometimes get lost in amongst other users long output, and they are wasteful of paper. And if you hardcopy large messages, you may not always care to wait around while the message is formatted for hardcopy. LAFITEHARDCOPYBATCHFLG is provided to allow you to postpone the hardcopying until it can be done all at once. When this flag is true, Lafite ``batches'' your hardcopy requests, and doesn't actually print them until you do an Update, at which point it sends them all to the printer in one batch. When you have hardcopy pending, the Hardcopy button is speckled to remind you of this fact. The Update button has an additional choice Do Hardcopy Only in case you want to get your batched hardcopy printed without doing an actual Update. The behavior of LAFITENEWPAGEFLG when batching hardcopy is that it applies only to the messages selected at each Hardcopy invocation; each new set of messages starts on a new page, independent of the setting of LAFITENEWPAGEFLG. LAFITEHARDCOPYBATCHFLG is initially NIL. LAFITEHARDCOPY.MIN.TOC If non-NIL, is a positive number. Whenever Lafite is instructed to produce hardcopy for more than LAFITEHARDCOPY.MIN.TOC messages, it also produces a table of contents as a cover page for the hardcopy. Currently, this flag is only noticed if LAFITEHARDCOPYBATCHFLG is NIL. Initially NIL. LAFITEDISPLAYAFTERDELETEFLG If T, Lafite will display the next message if you delete the one that is in the message display window and the next message is undeleted and has not been examined (i.e., it is marked with a ``?''). If ALWAYS, then it will display the next undeleted message even if it has already been seen. Initally, T. T is roughly Laurel semantics, ALWAYS is Hardy semantics. LAFITEMOVETOCONFIRMFLG Controls whether Lafite requires confirmation of the Move To command. If ALWAYS, all moves require confirmation; if LEFT, then only left-button moves (selecting the destination from a menu) require confirmation; if MIDDLE, then only middle-button moves (using the ``default Move To'' folder) require confirmation; if NIL, then no moves require confirmation. Initially ALWAYS. LAFITEBROWSERREGION, LAFITEDISPLAYREGION, LAFITEEDITORREGION These are REGIONs which are used to describe where the primary (i.e. first) window of each type is to be placed on the screen. Initally, they are set to something ``reasonable'' for the standard initial display configuration. If you set them to NIL then you will be asked to specify a region (via GETREGION) the first time any such window is created. LAFITEDISPLAYFONT, LAFITEEDITORFONT, LAFITEHARDCOPYFONT These are the fonts used for displaying messages, composing messages, and making hardcopy. You may change them individually. They should be FONTDESCRIPTOR's as returned by FONTCREATE. Initially, they are all TimesRoman12. LAFITEBROWSERFONT The font used for displaying the table of contents in the browser window. Initially, Gacha10. LAFITEMENUFONT The font used for the items in all Lafite menus. Initially Helvetica10 Bold. LAFITETITLEFONT The font used for the title bar (``Lafite'') in the Lafite status window. Initially Helvetica12 Bold. LAFITESTATUSWINDOWPOSITION Specifies where the status window appears when Lafite is invoked. It is a POSITION or NIL (in which case you will be asked to specify a position when Lafite starts). LAFITEOUTBOXSIZE Specifies the number of delivered messages that should be retained in your outbox. As you send more messages, older ones fall off the end. Increasing this number gives you a longer ``history'' from which you can select and re-edit old messages, but this desire should be balanced with the knowledge that you are tying down the resources used by each of those messages. Setting LAFITEOUTBOXSIZE to zero or NIL disables the outbox feature: after delivery, messages completely vanish. LAFITEOUTBOXSIZE is initially 2. LAFITENEWMAILTUNE, LAFITEGETMAILTUNE (Dandelion only) These are lists of the form acceptable to the function PLAYTUNE, or NIL, in which case they are ignored. LAFITENEWMAILTUNE is played when Lafite discovers you have new mail waiting; LAFITEGETMAILTUNE is played when a Get Mail command completes. LAFITEENDOFMESSAGESTR, LAFITEENDOFMESSAGEFONT LAFITEENDOFMESSAGESTR is a string containing the text of the ``End of Message'' token displayed at the end of a message; LAFITEENDOFMESSAGEFONT is the font in which it is displayed. If LAFITEENDOFMESSAGESTR is NIL, then no ``End of Message'' token will appear. LAFITEIFFROMMETHENSEENFLG If true, then messages sent from you are considered ``Seen'' (and hence do not have the mark `?'), even though you have not yet displayed them. Initially T. LAFITEBUFFERSIZE The number of 512-character buffers used by the stream managing the file behind an open browser window. If you regularly receive very long messages, you might want to increase this to improve performance of Display followed by HardCopy or Move. Initially 20, which handles up to about 10,000-character messages. LAFITEMODEDEFAULT Determines the mode Lafite comes up in when more than one set of protocol implementations has been loaded. Initially NIL, which means that if there is a choice, Lafite simply waits for the user to choose a mode. LAFITESHOWMODEFLG Determines whether Lafite displays the current mode in the status window. If ALWAYS, it always does; if NIL, it never does; if T, it does only if there is any ambiguity (more than one set of protocol implementations has been loaded). Initially, T. Adding New Message Forms to Lafite The normal way to add new message forms to Lafite is to edit an existing form (or build one from scratch) and save it away using the `Save Form' menu item. You can also provide message forms that compute the text on the fly, as, for example, the `Lisp Support' selection does. To add your own items to the `Message Forms' menu, add a standard three-element menu item to the variable LAFITESPECIALFORMS and then set the variable LAFITEFORMSMENU to NIL (this is where the menu is cached). The three-element menu item should yield a LITATOM as its ``value'', that atom being interpreted as follows: 1. If the atom has a function definition, the function is called (with no arguments) and the returned value (a string or a TEdit TextStream) is used; 2. If the atom has a value, its value (a string or a TEdit TextStream) is used; 3. otherwise, a copy of the file by that name is used. For example, if TEdit wanted to add a message form that contained the date the TEdit was made (similiar to Lafite's bug report form) it could add ("TEdit Support" (QUOTE MAKETEDITFORM) "Make a form to report a problem with TEdit") to LAFITESPECIALFORMS; MAKETEDITFORM could be defined to be [LAMBDA NIL (PROG (OUTSTREAM) (SETQ OUTSTREAM (OPENTEXTSTREAM "")) (printout OUTSTREAM "Subject: TEdit: >>Subject<<" T) (printout OUTSTREAM "To: " TEDITSUPPORT T) (printout OUTSTREAM "cc: " (USERNAME) T) (printout OUTSTREAM "TEdit-System-Date: " TEDITSYSTEMDATE T T) (printout OUTSTREAM ">>Message<<" T) (RETURN OUTSTREAM] where TEDITSUPPORT and TEDITSYSTEMDATE are variables set by TEdit. Lafite supplies one function to make this kind of message form easier to construct: (MAKEXXXSUPPORTFORM SYSTEMNAME ADDRESS SYSTEMDATE) Creates a message form (a TEdit stream) to be mailed to the maintainers of SYSTEMNAME. SYSTEMNAME is the name of the subsystem (a string); SYSTEMDATE, if non-NIL, is a date (string) of importance to include in the message; and ADDRESS is the mail system address of the intended recipient(s). For example, if MAKETEDITFORM were defined as [LAMBDA NIL (MAKEXXXSUPPORTFORM "TEdit" "TEditSupport" TEDITSYSTEMDATE)] Then selecting ``TEdit Support'' in the Message Forms menu would produce a form such as the following: Subject: TEdit: >>Subject<< To: TEditSupport cc: vanMelle.pa TEdit-System-Date: 3-Feb-84 12:23:49 Lisp-System-Date: 3-Feb-84 18:13:22 Machine-Type: Dorado >>Message<< $$$$$$ $$$$HH$$6H6H$$$$$$$ + +TIMESROMAN GACHA + +TIMESROMAN +TIMESROMAN +TIMESROMAN + +TIMESROMAN + HELVETICA +TIMESROMAN  +TIMESROMAN +TIMESROMAN + l + +$ + > + + + + + + + +r + +  + & + +  + +4 +  +i +f + +D + + + + + +  + +  +h +} + +4 +b + +# +b + +& + +) + + +L + +H +: + + 9 + D +  + o +  + +  +9 + 7 + + + N + ( + ! + +O +  +R +  + + +U +D +A +  + + +p +  + +  + + + + + M + , +  + 4 +8 +y +0 +  + + + + + + + + +h +} +  + $ + 9 +> +< + 1 +% +3 +& +  + + + + p + + +a +  + + + + + + +K +f +m + +8 +F +J + A + + + +9 + + + + d + + + +k +a +  +S + +  +C +T +0 + + + +B + + + +4 + +@ + + + +n + * + +H + + +  + 6 + + + + + + +Q +B + +W + + + +% +! +> +H +Q +P +  +x +2 +- + + H + +) + + + ++ + % + + + +} +  + + +` + _ +P + + + + + + + +? + +A +' +  + + + + . + + + +G +  +& + + + +  +- + +  + + +7 +  + +- + 3 +  + +x +" +m + +* +> +H + 0 +? + + +  + + ( +e + + + + . + + 7 +  + + = + +  + p +  + + H +  + + * + + + + P +G + +s + + ` + +  +y + + + +  + + + + D +X + B +W +  + + +  + + +  +Y +{ + + + + +  + +_ + +; + + J +% +_ +` +1 + + + + + + + +0 + - + + + + + +) + + ` + + N + + g + + A + + +M + + | + +K + +$ + I + +# +< +. + + + d ++ + +0 + + + + + : + + v +\ + + N + + +v + +# + + +Q +< + +P +7 + +(4 + +  +/?53I/ +  +r +3 K + + + +* + + +B +: + +  +  +@ +h + + + +& +% + + + + + + +@z \ No newline at end of file diff --git a/library/lafite/docs/release-notes/Lafite-Jun-88.TEdit b/library/lafite/docs/release-notes/Lafite-Jun-88.TEdit new file mode 100644 index 00000000..ef67ac06 Binary files /dev/null and b/library/lafite/docs/release-notes/Lafite-Jun-88.TEdit differ diff --git a/library/lafite/docs/release-notes/Lafite-Update.TEdit b/library/lafite/docs/release-notes/Lafite-Update.TEdit new file mode 100644 index 00000000..b7f26aae Binary files /dev/null and b/library/lafite/docs/release-notes/Lafite-Update.TEdit differ diff --git a/library/lafite/docs/release-notes/LafiteImpl.ted b/library/lafite/docs/release-notes/LafiteImpl.ted new file mode 100644 index 00000000..298ee54b --- /dev/null +++ b/library/lafite/docs/release-notes/LafiteImpl.ted @@ -0,0 +1,446 @@ +I assume you are willing to deal with a completely unpolished interface, so I'll tell you what the current truth is about the Lafite on Library> and in the latest Next>Full.sysout. What follows might be viewed as the start of an implementor's manual. It is not, of course, anything I'd be willing to publish as a programmer's manual, but perhaps your experience will help us define what one might wish the interface really to be. I'm quite willing to add small things as you see the need, though there is little hope for any major projects in the near term. So let me know how this matches your needs. My other reluctance, of course, is that internals, as these all are, are subject to change without notice, so I'd appreciate feedback on what parts you would like to see solidified into a supported interface. There are almost no direct functional interfaces to what you want, but with some record definitions I think you can get most of it. You thus need to LOADCOMP(LAFITE). In general, you should probably avoid replacing record fields, as there are usually interactions; if you need to replace a field for which there is no programmatic interface, let me know. Fetching fields should be fine. The important records are two datatypes, MAILFOLDER and LAFITEMSG. MAILFOLDER holds assorted facts and state about a single mail folder. The window property MAILFOLDER hangs off each Lafite browser window. Here are the most interesting fields: FULLFOLDERNAME, VERSIONLESSFOLDERNAME, SHORTFOLDERNAME -- various forms of the folder's name. FOLDERSTREAM -- a stream on the file behind the folder, if it's open. MESSAGEDESCRIPTORS -- an array of LAFITEMSG objects, corresponding to messages 1 thru #OFMESSAGES. Thus (ELT (fetch (MAILFOLDER MESSAGEDESCRIPTORS) of folder) n) returns the nth LAFITEMSG in folder. This field is only valid while a browser is open on the folder. FOLDERLOCK -- a monitor lock that should be acquired if you want to perform any operations on the folder. FIRSTSELECTEDMESSAGE, LASTSELECTEDMESSAGE -- number of the first and last messages currently selected (equal if only one selected). BROWSERWINDOW, BROWSERMENU, BROWSERMENUWINDOW, BROWSERPROMPTWINDOW -- pointers to parts of the browser window for this folder. NIL if no browser open on folder. (\LAFITE.GETMAILFOLDER folderName) -- this function returns a MAILFOLDER object for folderName, which should be either a full file name or a full name sans version number. If the result has a non-NIL BROWSERWINDOW field, there is a browser currently open on the folder, else not. (\LAFITE.OPEN.FOLDER folder access recog) -- returns a stream on the file behind folder. access and recog are as with OPENSTREAM. This is the standard way to get the stream (rather than the FOLDERSTREAM field), unless you're sure the file's open for the right access. Each message in a browser is described by a LAFITEMSG record. Its most interesting fields: PARSED? -- true if message has been parsed. Set by LAFITE.PARSE.MESSAGE.FOR.TOC, which also distributes the standard parse into the fields FROM, SUBJECT, DATE. DELETED? -- true if message is marked deleted. SEEN? -- true if message is marked seen (NIL => "?" in browser). MARKCHAR -- character code of message's mark. MARKSCHANGED? -- true if MARKCHAR has changed since last update. SELECTED? -- true if message is currently selected. MSGFROMMEP -- true if message is from the logged in user. # -- ordinal position of message in folder, from 1. BEGIN -- byte position in file of start of message, which is always the internal header that starts "*start*". MESSAGELENGTH -- length of message, including internal header. STAMPLENGTH -- number of bytes between the BEGIN position and actual start of message. START -- access field: byte position of the start of the actual message, viz., BEGIN+STAMPLENGTH. END -- access field: byte position of the end of the message, viz., BEGIN+MESSAGELENGTH. DATE -- date of message, actually just the 6 character string that appears in toc (so you can't give it to IDATE). FROM, SUBJECT, TO -- From, Subject, To fields of the message. The TO field is usually only parsed out if MSGFROMMEP has been observed to be true. Now, how to use all these: The value of the variable LAFITE.AFTER.GETMAIL.FN, if non-NIL, is a function to call immediately after Lafite retrieves mail from a server. It is called with two arguments, the MAILFOLDER, and a list of LAFITEMSG objects describing the new messages (which have already been appended to MAILFOLDER:MESSAGEDESCRIPTORS, securely stored in the file, but not yet displayed in the browser window). The messages have not yet been parsed, I believe. The function is called while in control of MAILFOLDER's monitorlock. Parsing messages. The function LAFITE.PARSE.MESSAGE.FOR.TOC sets all the fields in a LAFITEMSG that the toc needs, but you probably want more fields than that, so will need to do your own parsing. Lafite has a simple-minded but reasonably efficient parser that looks for header fields in a message (Field name followed by colon) and does something with them. It requires that you build a "parse table" describing what you want it to do. This is a list of lists, one for each field you want to parse. Each sublist is in the form ("FieldString" ResultFn . ResultArgs). Then "compile" the parse table by calling (LAFITE.MAKE.PARSE.TABLE table). The resulting compiled table can then be passed to this function: (LAFITE.PARSE.HEADER stream parseTable start end onceOnly) -- Stream is the stream where the message lives -- the folder's stream for message in a file, or a tedit stream for a message you're sending. parseTable is the compiled parse table. Start and End are byte pointers in stream (normally the START and END fields of a LAFITEMSG). Parsing automatically stops at the end of the header. onceOnly is true if you want parsing to end as soon as any one field has been successfully parsed. The parse proceeds as follows: the parser starts at byte position start and scans each line in the header, seeing if the field name matches (case-insensitively) a field in the parse table. If a match is found (the characters match up thru the colon), then the parser skips over any white space, then calls the ResultFn indicated in the parse table with two arguments, the stream (now positioned at the first non-blank character after the colon) and the ResultArgs from the table (this lets you multiplex one parsing function for several purposes). The function's job is to parse the rest of the field, leaving the stream positioned after the terminating , and to set freely the variable PARSERESULT as it wishes. PARSERESULT is what LAFITE.PARSE.HEADER ultimately returns. You may not need to follow that too closely. Lafite's standard use of the parser is to make PARSERESULT an alist; the following functions are interesting as resultFn's, or to help them. You can look at the variable LA.FULLPARSEFIELDS and LA.TOCFIELDS for examples. The former is used for a "full parse", such as the Answer command needs; the latter parse three fields out for the toc. (LAFITE.READ.TO.EOL stream) -- Reads the rest of the field, returning one long string. You should probably use this as the basis for all result fns, as it takes care of continuation lines and makes sure the stream is left properly at the end of the field. (LAFITE.READ.LINE.FOR.TOC stream Args) -- Reads the field as one big string and stashes it on PARSERESULT indexed by (CAR Args). If all of your resultFn's are this one, then your parse result ends up something like ((field1 "contents1")(field2 "contents2")...). The string is limited in length to 255 characters (a toc restriction); if longer, it is truncated. (LAFITE.READ.NAME.FIELD stream Args) -- This is almost the same, but no string length restriction, and it recognizes that some fields may have multiple occurrences (bad form, but allowable). If a field occurs twice, its alist entry has more than one string in its cdr: ((field1 "contents1a" "contents1b") ...). (\GV.PARSERECIPIENTS field registry internalFlg editWindow) -- This function takes raw strings from the output of LAFITE.PARSE.HEADER and produces a list of individual recipient names. Field is a string or list of strings, such as LAFITE.READ.NAME.FIELD might produce during the header parse. registry is the grapevine registry default for names without registries (defaults to DEFAULTREGISTRY). If internalFlg is true, the names returned are in internal form (name . reg); if NIL, the names are strings of the form "name.reg". editWindow is for error messages (true when sending mail). (LA.SETDIFFERENCE x y) -- like LDIFFERENCE, but treats x and y specifically as sets of strings, case-insensitively. (LA.REMOVEDUPLICATES x) -- removes duplicates from x, treating x as a set of strings, case-insensitively. Message manipulation. Most of these update the browser window appropriately. (SELECTMESSAGE msgDescriptor mailFolder) -- "selects" msgDescriptor, a LAFITEMSG object, in mailFolder. Does not deselect anything. (UNSELECTALLMESSAGES mailFolder) -- unselects all messages. (MARKMESSAGE msgDescriptor mailFolder mark) -- changes msgDescriptor's mark character to mark (a charcode). (SEENMESSAGE msgDescriptor mailFolder) -- mark msgDescriptor "seen". (DELETEMESSAGE msgDescriptor mailFolder) -- mark msgDescriptor "deleted". (UNDELETEMESSAGE msgDescriptor mailFolder) -- undelete msgDescriptor. Most of the browser commands consist of a function \LAFITE.nameOfCommand, some of which spawn processes named \LAFITE.nameOfCommand.PROC. Here's the one for MoveTo: (\LAFITE.MOVETO.PROC window mailFolder destinationFolder item menu shortOutput oldFileP) -- moves all selected messages from mailFolder to destinationFolder. Greys out item of menu while it's working (the BROWSERMENU field of mailFolder gets you the menu). When finished, if exactly one message was moved, and it was the one currently displayed, does the "display after delete" action. shortOutput is the folder's name (in short form, but it really doesn't matter). oldFileP is true if the caller believes, but has not yet verified, that destinationFolder describes an existing folder (this is true if the folder was on the folder menu). window is mailFolder's BROWSERWINDOW. As I said, "unpolished". You probably really want the not yet defined subfunction of that: (\LAFITE.MOVE.MESSAGES mailFolder msgDescriptors destinationFolder). NILNILr +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN + +GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +GACHA +Q +TIMESROMAN + +GACHA +N +TIMESROMAN +NILNIL +TIMESROMAN +HNILNILGACHA + +TIMESROMAN +GACHA + +TIMESROMAN +GACHA +( +TIMESROMAN +HNILNIL GACHA +; +TIMESROMAN +HNILNILGACHA + +TIMESROMAN + GACHA ++ +TIMESROMAN + GACHA + +TIMESROMAN +.GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +GACHA + +TIMESROMAN + GACHA +M +TIMESROMAN +HNILNIL +GACHA +` +TIMESROMAN +HNILNILGACHA + +TIMESROMAN +GACHA +[ +TIMESROMAN +HNILNIL GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +GACHA +> +TIMESROMAN +GACHA + +TIMESROMAN +GACHA +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA +( +TIMESROMAN + +GACHA +} +TIMESROMAN +GACHA + +TIMESROMAN + GACHA +C +TIMESROMAN +NILNIL +TIMESROMAN +NILNILGACHA +c +TIMESROMAN + +GACHA +? +TIMESROMAN + GACHA +B +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL, +TIMESROMAN + GACHA +' +TIMESROMAN +NILNIL +TIMESROMAN +HNILNILGACHA +- +TIMESROMAN +GACHA +< +TIMESROMAN +GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +HNILNILGACHA +' +TIMESROMAN +HNILNILGACHA +$ +TIMESROMAN +GACHA + +TIMESROMAN +HNILNILGACHA +& +TIMESROMAN +HNILNIL GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +HNILNIL GACHA ++ +TIMESROMAN +HNILNIL +GACHA +0 +TIMESROMAN +HNILNILGACHA +3 +TIMESROMAN +HNILNILGACHA +j +TIMESROMAN +HNILNIL GACHA +2 +TIMESROMAN +HNILNIL GACHA + +TIMESROMAN +GACHA +' +TIMESROMAN +HNILNILGACHA +J +TIMESROMAN +GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +HNILNILGACHA +A +TIMESROMAN +GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +HNILNILGACHA +g +TIMESROMAN +GACHA + +TIMESROMAN +HNILNILGACHA + +TIMESROMAN +GACHA + +TIMESROMAN +GACHA +2 +TIMESROMAN +GACHA +% +TIMESROMAN + +GACHA + +TIMESROMAN +HNILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA + +TIMESROMAN +GACHA +u +TIMESROMAN + +GACHA + +TIMESROMAN + GACHA +J +TIMESROMAN +GACHA + +TIMESROMAN + +GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +GACHA +L +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN + GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL] +TIMESROMAN + GACHA +q +TIMESROMAN +GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA +E +TIMESROMAN + GACHA + +TIMESROMAN +GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA +! +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA +^ +TIMESROMAN +GACHA +c +TIMESROMAN +GACHA +~ +TIMESROMAN +GACHA +U +TIMESROMAN +GACHA +l +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA + +TIMESROMAN + GACHA +J +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA +V +TIMESROMAN +NILNIL +TIMESROMAN +NILNILN +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN + GACHA +9 +TIMESROMAN + GACHA +5 +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA +( +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN + GACHA +` +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN + GACHA +9 +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN + GACHA +< +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA +6 +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +GACHA + +TIMESROMAN + GACHA + +TIMESROMAN + GACHA + +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +NILNIL +TIMESROMAN +)bz \ No newline at end of file diff --git a/library/lafite/docs/release-notes/ReleaseMsg.TEdit b/library/lafite/docs/release-notes/ReleaseMsg.TEdit new file mode 100644 index 00000000..76fcf9bb Binary files /dev/null and b/library/lafite/docs/release-notes/ReleaseMsg.TEdit differ diff --git a/library/lafite/docs/release-notes/Tasks.ted b/library/lafite/docs/release-notes/Tasks.ted new file mode 100644 index 00000000..aba33211 Binary files /dev/null and b/library/lafite/docs/release-notes/Tasks.ted differ diff --git a/library/lafite/docs/release-notes/TasksDone.ted b/library/lafite/docs/release-notes/TasksDone.ted new file mode 100644 index 00000000..b87573fa Binary files /dev/null and b/library/lafite/docs/release-notes/TasksDone.ted differ diff --git a/library/lafite/docs/release-notes/unixmail.tedit b/library/lafite/docs/release-notes/unixmail.tedit new file mode 100644 index 00000000..751044f9 Binary files /dev/null and b/library/lafite/docs/release-notes/unixmail.tedit differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-APPENDIXA.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-APPENDIXA.TEDIT new file mode 100644 index 00000000..5b1cec8a --- /dev/null +++ b/library/lafite/docs/users-guide/LAFITEMANUAL-APPENDIXA.TEDIT @@ -0,0 +1,8 @@ +1 A USER'S GUIDE TO LAFITE 1 A USER'S GUIDE TO LAFITE USING LAFITE COURTEOUSLY 1 USING LAFITE COURTEOUSLY 1 Appendix A: Using Lafite Courteously 6 The great art of living easy and happy in society is to study proper behaviour, and even with our most intimate friends to observe politeness; otherwise we will insensibly treat each other with a degree of rudeness, and each will find himself despised in some measure by the other. Boswell, London Journal (1762) 2 Foreward 1 This appendix is an edited version of ``Message System Mores,'' chapter 6 of the Xerox Laurel Manual, by Douglas K. Brotz, and the essay Message System Mores that Brotz published in ACM Transactions in Office Information Systems, Vol 1, No. 2. The material that appeared only in the ACM journal is copyright 1983 by the Association for Computing Machinery, Inc. Douglas Brotz was a member of the team at the Palo Alto Research Center (PARC) that designed Laurel, which is an electronic message system similar to Lafite that was written for the Xerox Alto. Through his involvement with Laurel, Brotz discovered patterns of electronic message system behavior that may apply to Lafite users. He also developed some rules for appropriate message system behavior, i.e., message system etiquette. Because many Laurel and Lafite users have found this essay helpful, we have edited it for inclusion here, making the references appropriate for Lafite and deleting information that appears elsewhere in the Lafite manual. 2 Introduction 1 This is an essay on manners, in particular, message system manners. Electronic message systems provide a new mode of communication that, while offering convenience, speed, and reliable delivery, also opens channels that may be abused. At the Xerox Palo Alto Research Center, we have designed and implemented an electronic message system that has quickly spread throughout the Xerox Corporation. Through its use, we have discovered many patterns of message system user behavior that appear to apply to electronic message systems in general rather than to the particular system that we built. The focus of this essay is not on the features of our system, but on observations of user behavior in the electronic mail environment in an effort to spread understanding of this new medium and to instruct users in proper behavior. The contents of this essay may be divided into roughly two kinds, objective observations of message system social phenomena and definitely biased suggestions of standards. The opinions expressed herein are solely those of the author. These opinions are not based on scientific studies or samples, but rather on certain intuitive feelings that have evolved through a close association with our system since its inception. 2 Communication Patterns 1 Part of the evolution of a society is the structure within which its members communicate. Face-to-face communication, both spoken and through gestures, has been with us for a very long time. Written communication and telephone communication have been employed for a substantially lesser amount of time. Nevertheless, these modes of communication have been around long enough to have developed certain standards of conduct and a framework in which reasonable communication can take place. The electronic message medium has existed for a much shorter period of time, perhaps 20 or so years. (I am purposely ignoring telegraphic communication, which has very different characteristics due to its long delays and high cost.) Electronic message systems on personal computers have been available for even less time, probably less than 10 years. In this time, standards of electronic communication have not yet had time to mature, so we are still groping toward a workable electronic-messaging society. In any of the mature communication media, each society places limits on what is considered acceptable behavior. Vulgar language or gestures are generally frowned upon in face-to-face communication, except in smaller sub-societies in which this mode of behavior is necessary for group membership. Shouting at close range is similarly considered to be in bad taste. Methods of dealing with such behavior in face-to-face communication run from mild rejection of the speaker to complete avoidance of that speaker in the future. As the number of human societies is large, and each has had much experience with this means of communication, the means employed for dealing with such situations are quite varied. Within each group, however, the methods used can be quite effective in stifling unwanted behaviors. I will list several kinds of situations that arise in the electronic message medium and means for dealing with them. Where possible, I will draw parallels to other more traditional modes of communication to illustrate acceptable manners. In addition, I will try to point out the ways in which communicating via electronic mail is different from the traditional communication media, and how this modifies the problems to be dealt with. 2 The Wrong Number 1 We all have dialed wrong numbers and received calls from people who have dialed wrong numbers. The protocol for handling such situations is simple, and arises naturally as a result of the way in which standard phone calls are initiated. A typical wrong number dialog may be as follows: Callee: Hello. Caller: Hello. May I speak to John? Callee: There is no one at this number by that name. I believe you have the wrong number. Caller: Oh. Isn't this 555-1234? Callee: No, it isn't. (And sometimes . . . ) This is 555-4321! Caller: Thank you. I'm sorry to have bothered you. In postal communication, receiving misaddressed mail or mail for a former resident who has moved is akin to the telephone's wrong number. The post office's suggested remedy is for the recipient to line out the address and remail the letter. The post office will then attempt to forward the letter to the correct address, deliver it to the proper address, or return the letter to the sender. Note that in both of these situations, it was not necessary to begin the actual conversation or open the letter. Enough information is exchanged at the outset to determine if the parties in the communication are the correct ones. This is usually not true when comunicating via electronic mail. In electronic message systems, it is seldom the case that a message sent to a particular name is actually delivered to a recipient with a different name. A different situation is (unfortunately) common when a recipient has a popular name. The problem is that several people may have the same last name, and some electronic message systems do not have convenient facilities for mapping a person's actual name into that person's message system name. Thus, a person named Doe may receive mail for ADoe, BDoe, etc. Here, the original error is committed by the sender, who did not consider that ADoe's message system name was actually ADoe, but just assumed that it was Doe. The parallel to this situation in the telephone medium is actually a bit more elaborate than the dialog given above. It is more like: Callee: Hello. Caller: Hello. Is Johnny there? Callee: Hold on, I'll get him. John: Hello? Caller: Hey Johnny, let's boogie on down to the hoedown. John: Who is this? Caller: Come on buddih, this is good old Bodine! John: I don't know any Bodine. Caller: Oh. Ain't this 555-1234? and so on. Notice that in this case a partial name match has occurred, and it is only later in the conversation that one of the parties discovers that something is awry. In the electronic mail case, it is nearly always the case that the message must be at least partially read to determine that it has reached an incorrect recipient. This situation can be (and has been) handled in several inappropriate ways. First (and worst), the incorrect recipient can just ignore the message. No one gains through such inaction. Second, the incorrect recipient may send a response to the sender of the form ``Stop sending me this trash!'' This is a bit more helpful, but not quite the best that can be done. Third, the incorrect recipient may send the correct recipient a message of the form ``Tell your senders what your name is!'' This is not even as good as the previous response, as a message system user cannot know all possible senders. Proper consideration by all involved can alleviate the ``wrong number'' syndrome considerably. Senders of messages should know their recipients. When sending a message, if you are not sure of a person's message system name, look it up. At Xerox PARC, the phone list has everyone's message system name correctly listed. Perhaps other organizations should do the same, and eventually a message-system-wide ``white pages'' may be published. Such lists help, but not if the senders don't use them. A message addressed to an individual tends to be more important than a message addressed to a distribution list, in that a reply from an individual is expected more than replies from anonymous members of distribution lists. The names contained in distribution lists are usually correct, so there is generally no misdelivery problem. However, senders type the names of individual addressees for important messages directly. Thus, when there is a misaddressed message, it is generally an important one. When you realize that a message is not for you, use the Forward command to send it back to the sender along with your polite comment that the message has reached a ``wrong number.'' Forwarding the message back is important, as the sender may not have a copy of that message any more. Once you have determined that you have received a ``wrong number'' message, stop reading it. A message sent through the message system may have personal material, and it is none of your business to peruse the entire message. (Many users who typically dispose of their received mail at a rapid clip take great delight in reading every last character of a misaddressed message%indeed, they consider it their solemn duty to do so.) It is for this reason that I do not suggest forwarding the message to the proper recipient. Determining who is the proper recipient is the job of the sender. It is presumptuous to believe that you know who the proper recipient is; you may actually forward the message to yet another incorrect recipient. Besides, determining the correct recipient may require reading more of the message than you ought to read. (If you think you know the message system name of the correct recipient by the time you realize that you are not the correct recipient, then you might include that name in your short covering note back to the sender. However, the mistaken sender should not expect correct identification of the intended recipient, just as he or she would not expect it in the telephone or postal mail systems.) Some further points to consider are these. The ``wrong number'' mishaps generally happen to people who have common names and whose system names are exactly their last names. The honor of having one's system name be exactly one's last name is generally historical (``I was the first Doe hired here, therefore I'm entitled to be Doe.PA forever!'') A reasonable solution would be that our system administrators ensure that no user has a name that is a suffix of another's, so that when ADoe arrives, then Doe has his or her message system name changed to BDoe, or whatever. In this way, the existing message system facilities will catch messages sent to Doe and return them as having been sent to a nonexistent name, at which point the sender can look up the correct message system name. 2 Rudeness and Vulgarity 1 The electronic mail medium joins several disparate properties of other communication media in an interesting way. The display of mail on a personal computer is a rather personal experience. Certain feelings of privacy and ownership pervade a personal computer user's relationship with his or her machine. Thus, the process of reading one's own electronic mail includes many of the personal aspects of face-to-face communication. On the other hand, sending electronic mail is much more impersonal. The recipient is not present, and nearly none of the social strictures that govern one's face-to-face communication are present. The sender is also able to speak his or her piece completely, without any intervening exchanges with the recipients that might moderate the entire business. This situation is enhanced when the recipients are not named directly, but are addressed indirectly through an impersonal distribution list. This imbalance in attitudes between sender and recipient has wide-ranging consequences. One obvious consequence of this imbalance is that opinions expressed and the language used to express them in messages can be wildly inappropriate to the customs and expectations of the recipients of such a message. A reader may justifiably feel slapped in the face by a message he or she considers to be in extremely bad taste. An interesting feature of the most annoying messages is that they tend to come from some ``other'' part of our messaging community. Julian Orr at PARC has observed that the most serious exchanges of antagonistic messages in our network have occurred shortly after some previously isolated message communities have joined. When the two societies meet and exchange messages, for some period the tone of the ``other'' community's messages has offended members of ``our'' community. After an adjustment period, the two communities come to some understanding and establish norms for their intercommunication. This understanding typically involves identification of subjects whose discussion will cease to cross community boundaries. The development of the junk mail lists in our Palo Alto and El Segundo, California registries illustrates this point. Both communities established Junk^ distribution lists for people interested in any for sale ads, announcements, random comments, etc. A slow link between these two locations was replaced by a faster one, and the volume of message traffic between the two communities increased dramatically. The two lists, Junk^.PA and Junk^.ES, were combined into an AllJunk^ list. However, even though the stated purpose of both Junk^ lists was ``anything goes,'' many PA registrants felt the ES junk mail was beyond the bounds of good taste. In other words, ``their junk is much worse than our junk.'' A majority of the original members of these lists withdrew from the Junk^ lists, and many splinter lists developed, ranging from Whimsy^.PA (``lighthearted mail for PA'') to @CrankMail.DL (a widely used private list in El Segundo). This is a history of two communities that seem to have similar characteristics. The implications for new message networks linking quite disparate communities are that more serious problems are likely to develop. When rebuked for inappropriate behavior, errant senders have been known to say ``I didn't intend it that way!'' This is not good enough. The damage has already been done. The only remedy is for senders to think about what they are saying and to whom they are saying it. The message system to date has been fairly unrestricted. Only as long as the society of message system users practices self-restraint will such a freewheeling communication medium be tolerated. There are several means of applying institutional censorship to the message system traffic, means that we hope will never need to be implemented. 2 Message System Costs 1 Many of the problems associated with improper use of the message system are exacerbated (caused?) by the lack of charging for message system usage. In nearly all other modes of communication, ``sending a message'' implies a certain cost (or risk), which rises with the number of recipients that are being reached. Free speech is, in this sense, not free at all. Certainly in a free society, one can say what one pleases, but not without paying for the means to say it. Let me illustrate this with some examples. In nearly every communication medium, costs for the use of that medium are borne by the sender of messages. Postal mail requires the sender to pay for a stamp for each copy of a message that is sent. Telephone service is charged to the originator of calls, and each call (in general) goes to only one recipient. Broadcasting messages via radio or television requires a large investment on the part of the sender. The costs of printing handbills or posters are likewise borne by their authors. Public speeches, if they are to reach a large audience, require use of sound systems, etc., that are paid for by the speaker. It may be argued that recipients do pay some of the costs for using some of these systems. However, these costs (the price of a radio receiver, basic telephone service, etc.) are generally constant; they do not increase as received message usage increases. A receiver's cost for electronic mail is similar in this respect in that the cost of a workstation on which the message system runs is borne by the receiver. Some other modes of communication do require explicit payment by the receiver. Commercial films, books, magazines, and records fall into this category. However, publication of these materials does involve a substantial financial risk. Material that is not likely to be well received is seldom published, and when it is, large costs are often incurred by the publisher. Electronic mail as it is usually implemented has a very different cost structure. The cost for a sender is minimal. It essentially consists of the time it takes to compose and send a message. If time is considered the major cost factor, then it is the recipients who pay dearly for the messages they receive. When the amount of time each recipient spends on a message sent to a large distribution list (even if a quick scan of part of the message followed by a Delete), is summed over all recipients, this is easily much more than the time consumed by the sender of that message. While we would like to keep the free structure of a message system, where any user can send any message to any other users, this freedom must be used with some care. When electronic message systems become widespread, they will undoubtedly change their cost structures to match those of the more traditional communication systems. 2 Unsolicited Mail 1 The existence of large public distribution lists in our message system makes it easy for a sender to reach a very wide audience. Each distribution list has a distinct purpose, e.g., lists of people interested in particular topics, lists of employees in certain organizations, lists of members of particular projects, etc. Some lists are used primarily to keep track of all users of the message system. These include such lists as AllPA^.PA, AllES^.ES, etc., which contain the names of all individuals in those particular registries. There are also some lists maintained on a purely geographical basis, e.g., PaloAlto^.PA, which lists all message system users in Palo Alto, California. This is not necessarily the same as AllPA^.PA, which includes people in the PA registry, but who may not actually work in Palo Alto. The audiences addressed by these lists should not be considered captive audiences for all users of the message system. At Xerox PARC, the purpose of any distribution list may be discovered by any user by running the Maintain program. Although all lists are (currently) available for use by any message system user, many lists, e.g., AllN^.N where N is a registry name, should not be used by anyone who doesn't have a very good reason for doing so. Many distribution lists exist for the enjoyment of their members who wish to receive items of interest to them. One should feel free to send an announcement of an upcoming musical event in Northern California, for instance, to Music^.PA. Such a message is quite inappropriate to send to AllPA^.PA, PaloAlto^.PA, etc. There are lists of message system users who have agreed to suffer through any and all messages. These lists (Junk^.PA, various @CrankMail.DL files, etc.) are the only lists to which ridiculous messages may be sent without incurring the justifiable wrath of message system users. A message system user should understand when a message is appropriate to send to all people in his or her work group. Social values are different in different locations, and the members of each group should understand what they are. It has been observed that messages that are sent to audiences wider than the sender's immediate group are the ones that cause the most trouble. Unfortunately, unsolicited messages have continued to be sent to inappropriate lists. Examples of inappropriate messages for standard organizational or geographic lists are: ``Does anyone know how to get my Alto fixed?'' ``This is to let everyone in the message system world know that my phone number has changed.'' ``I want everyone to know that I really like my roofing contractor.'' I'm sure that each user of the message system can recall some other similar gem. The following sections explore some of the consequences of unsolicited mail. 2 The Chain Reaction 1 To add insult to injury, after some piece of particularly ridiculous mail has been broadcast to an inappropriate audience, it invariably follows that some recipients cannot control their urge to make even bigger spectacles of themselves by sending their two cents' worth to everyone who received the original nonsense. While the original event is thought by many message system users to be annoying, the latter is considered to be downright stupid. Remember that once you push the Deliver button and watch the last chance to cancel fade away from your screen, there is no way to erase your comments from the collective memory of your peers. I would like to list some of the typical responses that have been sent not just to the original perpetrator, but to the entire list of victims. ``Your message is inappropriate to send to all these good people.'' ``If you don't like junk, then get off Junk^.'' ``How do I get off Junk^?'' and, my favorite, ``Do you realize that if all of us replied to all of us (as I am doing right now) that the number of messages that would be sent would exceed the number of atoms in the known universe . . . .'' It is my opinion that bombarding only the original sender of a ridiculous message with equally nonsensical replies is poetic justice. Use the Reply-To field to counteract the chain reaction phenomenon. However, there are situations in which replying to the entire list of original recipients is appropriate. In these cases, send the message without a Reply-To field, so that recipients who use Answer will get forms with all recipient names and lists included as recipients. One final note on this topic. Although Lafite provides these mechanisms to help break chain reactions, the ultimate responsibility for messages sent lies with their senders. Always check the list of recipients in any message you are about to send. 2 Off-the-Record Responses 1 There are many situations in which a user submits a question to a wide audience, say to a distribution list of people interested in such questions, and indicates that he or she will collect responses and later make them public. This is a most reasonable thing to do, and it helps to reduce the chain reaction effect. Be sure to include a Reply-To: >>Self<< field when performing such services for your audience. A note of caution is in order here. Messages should be considered private unless otherwise indicated. If your intention is to publish the responses, then by all means make that intention clear in the same message that poses the original question. If your message did not make that intention clear, and you decide that you would like to publish the responses, then follow up on each response asking whether you may do so. If the intention to publish responses is clearly indicated in the original message, then publication of any response is fine, as long as that response does not explicitly mention that it should be considered private. 2 Masquerading 1 On occasion, people have received messages from fictitious senders, or even worse, from someone masquerading as another real message system user. This is a most serious breach of message system etiquette, and should be considered so by all message system users. A fictitious From field is legitimate when a valid Sender field is included. For instance, messages that are properly signed with an organization's name, say ``The Lafite Group,'' may be sent by explicitly typing a ``From: The Lafite Group'' line in the message header. Lafite will notice that a From field is already there, and it will include a Sender: User Name line in the delivered message instead of its usual From: User Name line. Any time you receive a message that has a strange From field, you may check the Sender field for the actual sender. By a ``masquerader'' I mean someone who subverts the normal mechanisms embedded in the standard message system programs to send messages of dubious value, without having his or her name appear in such messages. This action is possible not only in electronic message systems, but in other more traditional communication media as well. Masquerading as another may be a criminal act when committed using traditional communication media, with penalties specified in laws that prohibit libel, slander, and fraud. Other situations, such as telephone ``breathers,'' are similarly outlawed. Masquerading is the most serious social problem that we deal with in our message system. It occurs very rarely (three times to my knowledge), but when it does, our message system administrators make every effort to discover the perpetrator. The consequences may be serious, and the discovered perpetrators have all apologized publicly. I quote without reference from one such apology made by a masquerader who saw the error of his ways: ``It is clear that any abuse of the message system, however lighthearted the intent, has repercussions far beyond what one might expect.'' At this time, I do not know of any court cases involving libel, slander, etc., in an electronic mail context. Such cases are sure to arise when electronic mail does become more widespread. Masquerading in the message system is not cute or clever. Don't do it. 2 Wizards Versus Naive Users 1 This section is addressed mainly to the wizards who should know better. The population of message system users covers a broad range, from those who have knowledge of the most arcane details of a system to those who just barely understand the basics of using that system. When you send a message to a wide audience, be considerate of the naive users, who may be confused by technical jargon. This admonition extends to those who are using a new, restricted program. It does not help a recipient to hear ``Oh you're using that old program. Well, I guess you're stuck.'' Just don't mention such things to users who cannot take advantage of them. 2 The Moral of This Tale 1 The moral of all this is simple: Be considerate. As we strive toward this goal, everyone's use of the message system will become even more of a joy than it already is.(LIST ((PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC) STARTINGPAGE# 69) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD RIGHT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (270 12 288 36) NIL) (HEADING NIL (HEADINGTYPE FOOTINGR) (54 27 558 36) NIL) (TEXT NIL NIL (54 54 504 723) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD LEFT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (54 12 288 36) NIL) (HEADING NIL (HEADINGTYPE FOOTINGV) (54 27 558 36) NIL) (HEADING NIL (HEADINGTYPE VERSOHEAD) (54 762 558 36) NIL) (TEXT NIL NIL (54 54 504 684) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD RIGHT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (270 12 288 36) NIL) (HEADING NIL (HEADINGTYPE FOOTINGR) (54 27 558 36) NIL) (HEADING NIL (HEADINGTYPE RECTOHEAD) (54 762 558 36) NIL) (TEXT NIL NIL (54 54 504 684) NIL)))))5 (0 130 0 286)5 (0 130 0 286)<2(0 130 0 130 0 286)T<(0 130 0 130 0 286)T; (0 130 0 130 0 286)B2(0 130 0 130 0 286)TB(0 130 0 130 0 286)T;(0 130 0 130 0 286)5 (0 130 0 286)62(0 286)T6(0 286)T/(0 286)/ (0 286)(( . /2T/T..fB PAGEHEADING VERSOHEADB PAGEHEADING RECTOHEADA PAGEHEADINGFOOTINGVA PAGEHEADINGFOOTINGR.MODERNMODERNMODERN +MODERN + HRULE.GETFNMODERN + HRULE.GETFNMODERN + HRULE.GETFNMODERN + HRULE.GETFNMODERN +  HRULE.GETFNMODERN  HRULE.GETFNMODERN  HRULE.GETFNMODERNWU. HRULE.GETFNMODERN  HRULE.GETFNMODERN; HRULE.GETFNMODERN HRULE.GETFNMODERN   )  + HRULE.GETFNMODERN   HRULE.GETFNMODERN   %f"@4  (  P\jc HRULE.GETFNMODERN HRULE.GETFNMODERNKJh HRULE.GETFNMODERN HRULE.GETFNMODERNptHK HRULE.GETFNMODERN HRULE.GETFNMODERN8RdX{/_F HRULE.GETFNMODERN HRULE.GETFNMODERND0X HRULE.GETFNMODERN HRULE.GETFNMODERN HRULE.GETFNMODERN  HRULE.GETFNMODERNf ; ~JC HRULE.GETFNMODERN HRULE.GETFNMODERN HRULE.GETFNMODERN HRULE.GETFNMODERNk&z \ No newline at end of file diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-APPENDIXB.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-APPENDIXB.TEDIT new file mode 100644 index 00000000..faf868b7 --- /dev/null +++ b/library/lafite/docs/users-guide/LAFITEMANUAL-APPENDIXB.TEDIT @@ -0,0 +1,32 @@ +1 A USER'S GUIDE TO LAFITE 1 A USER'S GUIDE TO LAFITE USING LAFITE AT XEROX 1 USING LAFITE AT XEROX 1 APPENDIX B: USING LAFITE AT XEROX 6 The main part of this manual tells you how to use Lafite at client companies. However, Lafite may be used somewhat differently at the Xerox site where you work. For example, you may use a message transport system known as Grapevine instead of the NS system; or you may use both systems. Or your site may use both Lafite and Laurel (a mail system similar to Lafite that was written for the Xerox Alto). This appendix gives you the specialized information you may need to use Lafite within Xerox. Lafite use at Grapevine sites is described first. This section includes the documentation for Maintain, the program used to maintain Grapevine public distribution lists. It also tells you how to send Lafite messages to ARPANET recipients. Next described is Lafite use at sites having both the Grapevine and NS systems. Then there is a short description of some Lafite-related packages currently available only within Xerox. The final section describes the differences between Laurel and Lafite. Note: this appendix was not indexed due to the difficulty of creating and maintaining separate customer and internal indexes. 2 The Grapevine Mail System 1 For about five years most Xerox sites have used the Grapevine electronic message transport system; it was for this system that Lafite was originally developed. At the present writing, Xerox is in the process of converting from Grapevine to the NS system. Some sites use only NS mail, some Grapevine, and some both. For the most part, you use Lafite with the Grapevine system in exactly the same way as with the NS system. The four major differences are the mail protocols, the forms of recipient addresses, the ability to send mail to ARPANET recipients, and the way in which public distribution lists are maintained. Grapevine Protocols 1 The Grapevine system uses its own set of mail protocols, which you can obtain by loading the Library package file MAILCLIENT.DCOM. Simply type (LOAD '{FILESERVER}MAILCLIENT.DCOM in the executive window. Grapevine Recipient Addresses 1 A Grapevine recipient address has two parts separated by a period, in the form Recipient.Registry. The first part is the identifier for the recipient, usually that person's last name. If there are two or more people with the same last name in the same registry, each is usually identified by his or her first initial plus the last name. The second part of a Grapevine address is the registry name. A registry is no more than a device for grouping related names. The registry name helps the mail system determine which mail server has the in-box for the recipient. Most registry names correspond roughly to ``campuses'' of activity within Xerox, which should make them easier to remember. Lafite allows you to omit the registry name for recipients who are in your registry. You can find out what your local registry is by typing DEFAULTREGISTRY at the prompt in your executive window. DEFAULTREGISTRY is the global variable that names your local Grapevine registry; it is used if your log-in name does not include a registry. This variable is normally set in your initialization file. Grapevine Registries 1 At present, the following registries exist: ARPA A pseudoregistry used to forward mail to people on the ARPANET and points beyond. AUTO A registry for software-driven functions requiring automatic access and Grapevine authentication. CHOLLA A registry for PARC/ICL, Palo Alto, California (no individuals in this registry). DC A registry for the District of Columbia. DLOS A registry for Dallas, Texas. EOSA and EOS A registry for associates or affiliates. ES A registry for El Segundo, California. FX A registry for Fuji Xerox, Japan. GUEST A registry for Palo Alto, California. HENR A registry for Henrietta, New York. LB A registry for Leesburg, Virginia. OGC A registry for the Office of the General Counsel. OSDA and OSD A registry for associates or affiliates. PA A registry for Palo Alto, California. PASA A registry for Pasadena, California. RX A registry for Rank Xerox, Great Britain. SIEMENS A registry for the Communications and Information Systems Group, Private and Special-Purpose Networks Division at Xerox XSG, OSD, Palo Alto, California. STHQ A registry for the Xerox Corporate Headquarters, Stamford, Connecticut. SV A registry for Sunnyvale, California. WBST A registry for Webster, New York. X A registry to be used by people in many geographic locations. XRCC A registry for the Xerox Research Centre of Canada, Toronto, Canada. Grapevine Distribution Lists 1 The Grapevine system supports over 1,500 distribution lists, some of which are work related and some of which are purely for fun. You can obtain a complete distribution list directory, giving the name of each list plus a short description of its purpose, by printing {Indigo}GV>DLMap.Txt. Grapevine distribution list recipient names end with the character ``^,'' in the form AISBU^.PA. The public distribution lists for each registry are stored on mail servers and are maintained by the administrators of that registry, by the owners of the lists, and in some cases by the members of the lists. To create a public distribution list you must contact an administrator for your registry, who will make sure that your proposed name does not conflict with any others, and who will create the list for you. You can get your name added to appropriate lists by contacting the owners of those lists or by using the Maintain program (see below). If you cannot make a desired change to a public list yourself, send a message to the owners of the list. In Grapevine registries, by convention, the owners of a list named List^.Registry are listed in the companion list Owners-List^.Registry. Delivery to Distribution Lists. If a recipient list includes public distribution lists, you must confirm the delivery by including a Reply-To field in the message (see chapter 9). If you do not include a Reply-To field before selecting Deliver, Lafite will give you a special Reply-To Field menu, asking you to choose between four options. The options are to send the message as is, have recipients reply to yourself, have them reply to someone else, or to abort the message. This is intended to minimize unintentional deliveries to large distribution lists. ARPANET Messages 1 The ARPANET (Advanced Research Projects Agency Network) is a network linking ARPA research sites, including some Xerox sites. The Grapevine system is connected to the ARPANET, so you can correspond with individuals at ARPA sites outside Xerox. As of this writing, ARPANET individual and distribution list addresses are in the form Name@Host.ARPA. However, all ARPANET addresses are gradually being changed to domain names. The primary Xerox address, Xerox.ARPA, will soon become Xerox.COM; external ARPANET addresses are also being changed. The name changes are not expected to greatly inconvenience Xerox ARPANET users. The current Xerox address will be supported for some time after the change, so you can receive mail from people who don't yet have your new address. If you send mail to an obsolete address, the ARPANET mail gateway will insert the proper address in the message header, but it is a good idea to keep an eye out for address changes in the correspondence you receive and update your private list of addresses accordingly. You don't have to update ARPANET addresses in any Grapevine distribution lists you own, because ARPANET names on Grapevine distribution lists are kept current by Xerox network administrators (who periodically run a program to update all the names). If you want to verify an ARPANET address, you can search for it in the ARPANET host table stored on {Indigo}ARPANET>Hosts.Txt. The first name in a host entry list is the primary name and the one you should be using. ARPANET messages sent via Grapevine undergo some special processing. Because many mail systems receiving the mail you send over the ARPANET cannot process the long lines contained in Lafite messages, carriage returns are automatically inserted to make each line less than 72 characters long if there are any lines of more than 90 characters within the first 5,000 characters of the body of your message. If you have already inserted carriage returns to make your lines slightly longer than 90 characters and you don't want your message to look unaesthetic, include a ``Line-Fold: No'' line in your header. ARPANET Distribution Lists. ARPANET distribution lists are not maintained at any one, central location. Instead, they are administered locally by interested sites; for example, SF-Lovers@Rutgers is maintained at Rutgers. When you send a message to an ARPANET distribution list address, it goes to the appropriate host, who sends it to all the members of the list. Some hosts anthologize messages for certain lists (such as SF-Lovers); that is, someone at the host site periodically collects messages from members and sends anthologies of them out to everyone on the list. Almost every ARPANET distribution list has a Xerox-internal redistribution list, so that all Xerox members are actually members of the redistribution list. For example, the redistribution list for SF-Lovers@Rutgers is XeroxSFLovers^.PA. You use Maintain to add yourself to the redistribution list of an ARPANET list in the same way you would add yourself to a Xerox distribution list. If you want to add yourself to (or make another administration request regarding) an ARPANET list that does not have a Xerox redistribution list, send a message to DistributionList-Request@Host. Other Forms of Grapevine and ARPANET Addresses 1 Lafite recognizes three special forms of address that contain arbitrary text in addition to a valid Grapevine or ARPANET address. The first form is Human Sensible Name . For example, if you wanted to include Cheryl Jones's first name in her address you could write it as Cheryl Jones . The area outside the angle brackets can contain any text except for certain prohibited characters: parentheses, angle brackets, commas, colons, semicolons, and quotation marks. The second form of address is Actual Address (Comments). You could, for instance, send an invitation to Jones.PA (and spouse). You can include any characters within the parentheses except additional parentheses. The third form of address is ``Comments'' . For example, you could send a message to ``Special Attn: Sybalsky, Shih'' TEditFriends^.PA. Any of the prohibited characters can be included within the quote marks except additional quote marks. Maintain 1 Maintain is a Lisp Library package used only within Xerox for maintaining Grapevine public distribution lists and changing your Grapevine password. To load Maintain, type (LOAD '{FILESERVER}MAINTAIN.DCOM) in your executive window. To enter Maintain, type (MAINTAIN). Maintain will try to log you in automatically with your current user name and password. If that fails, then you may log in using the Login command in Maintain (see below). How to Issue Maintain Commands 1 Maintain has its own prompt sign, in the form GV:. To issue a command in Maintain, you must type after the prompt sign only the initial letters that uniquely identify that command; i.e., as soon as enough of a word (usually one letter) has been typed, Maintain will complete that word for you. For instance, when typing the Add Friend command, you need only type A F. Throughout this section, the letters that Maintain fills in are given in square brackets. Once you have issued a command for a specific distribution list or individual, Maintain will fill in that same name for the next command you type. If the name is appropriate for that command, press the space bar or carriage return to confirm it. If the name is not appropriate for the command, begin typing the correct distribution list or individual's name to replace it, ending by hitting the space bar or carriage return. The Login Command 1 To log into Maintain, type L[ogin]after Maintain's GV prompt. Now type your name and registry and press the carriage return. Maintain will prompt you for your password, each character of which will appear as an asterisk on the screen. Grapevine maintains its own copy of your password, and the password you give here must be the one Grapevine knows. If you give your password successfully, Maintain will inform you that you are logged in. Once you are logged in, you may proceed to issue other Maintain commands. If you cannot log in, because you have forgotten your password or for some other reason, then you will have to ask an administrator for your registry to issue a Change Password command. Maintain automatically logs in the current user when it starts up, so you only need to issue the Login command if you wish to change your identity for some reason. The ? Command 1 To obtain a list of Maintain commands, type a question mark after the GV prompt. You will see that the commands are Add Friend, Add Member, Add Owner, Change Password, Change Remark, Login, Quit, Remove Friend, Remove Member, Remove Owner, Type Entry, Type Members, and ^YEnter Lisp. Each of these commands is described below. The Type Entry Command 1 The Grapevine system has a name data base of entries giving information about groups and individuals. Groups represent distribution lists and some other groups that are unimportant to casual users, such as access control lists. Individuals represent human users and server computers. There are also ``abstract users'' that are syntactically individuals but actually name a group, such as LafiteSupport.PA. To read an entry in the data base, type T[ype] E[ntry] after the GV prompt. Maintain will ask you for the name of the group or individual whose entry you want to read, then print the entry. When it is finished, it will return you to the GV prompt. An entry for a group has four components: the remark, the number of members, a list of owners, and a list of friends. The remark describes the purpose of the group; for example, the remark for the distribution list Books^.PA is ``Resource for Readers (primarily reviews).'' The members are the individuals or other groups contained in the group. To obtain a list of members, use the Type Members command (described below). The owners are the people empowered to add and remove owners, friends, and members for the group. They can also set and change the remark. The friends are the people empowered to add and remove their own names to and from the group. If the list of friends is None, no one but the owners can add members to the list. If the list is an asterisk, anyone on the Grapevine system can add himself or herself to the list. If the list is of the form *. Registry, anyone in that registry can add himself or herself to the list, and so on. An entry for an individual has two components: connect site and mailbox site(s). The Type Members Command 1 To find out who the members of a distribution list are, type T[ype] M[embers] after the GV prompt. Maintain will fill in the words ``of group'' followed by a colon. Type the name of the distribution list after the colon and press the carriage return. Maintain will then print the list of members. If it is a very long list, your executive window may fill up, stop printing the list, and become highlighted in reverse video, a sign for you to hit the space bar to get the listing going again. Some members of a group may be groups themselves. To see the members of those groups, you can use extra Type Members commands. If you use Type Members for the special group Groups.Registry, you will obtain a list of all distribution lists for that registry. When Maintain is through printing the members of a distribution list, it will repeat the GV prompt. The Add Member Command 1 You can add yourself (or another person if you are an owner) to a distribution list by typing A[dd] M[ember] [name] YourName.Registry after the GV prompt. Maintain will print ``to group'' after which you should fill in the name of the distribution list to which you want to add your name. If Maintain prints ``done,'' you have successfully added yourself to the list. If it prints ``NoChange,'' you were already a member of the list. If it prints ``NotAllowed,'' you should send a message to the owners of the list, asking them to add your name. The Remove Member Command 1 You can remove yourself (or another person if you are an owner) from a distribution list by using the Remove Member command. This works in the same way as the Add Member command. The Add Owner Command 1 Use the Add Owner command to add an owner to a distribution list. This is not allowed unless you yourself are an owner. Otherwise, this works in the same way as the Add Member command. The Remove Owner Command 1 Use the Remove Owner command to remove an owner from a distribution list. This is not allowed unless you yourself are an owner. Otherwise, this works in the same way as the Remove Member command. The Add Friend Command 1 Use the Add Friend command to add a friend to a distribution list. You cannot do this unless you are an owner. Otherwise, this works in the same way as the Add Member command. The Remove Friend Command 1 Use the Remove Friend command to remove a friend from a distribution list. You cannot do this unless you are an owner. Otherwise, this works in the same way as the Remove Member command. The Change Remark Command 1 The remark is the description of the distribution list that Maintain prints when you use the Type Entry command. To change the remark, type C[hange] R[emark] after the GV prompt. Maintain will prompt you for the name of the group, then ask you to type the new remark followed by a carriage return. You cannot change the remark for a list unless you are an owner. The Change Password Command 1 You can change your Grapevine password using Maintain's Change Password command. Type C[hange] P[assword] after the GV prompt. Maintain will respond with ``for individual.'' Now type in your name and registry. Maintain will prompt with ``to be.'' Type in your new password, which will appear as a series of asterisks. Maintain will ask you to confirm your new password by typing it again. When you terminate this word with a carriage return or a space, Maintain will store it in the Grapevine data base. Be very careful when typing your new password, because if you make a mistake and can't reproduce the password later you will have to obtain the help of an administrator for your registry to correct it. After returning to the executive, you will need to reinvoke the Login command (see above) to continue using Lafite to get and send mail. The ^Y Command 1 If you want to drop into Lisp temporarily, then return to Maintain, type control-Y at the GV prompt. Maintain will fill in ``Enter Lisp'' and return you to the regular executive window prompt. To go back to Maintain, type OK. The Quit Command 1 To leave Maintain, type Q[uit] after the GV prompt. Maintain will ask you to confirm this command with a carriage return. 2 If You're on Both Networks 1 Because the Grapevine and NS systems are totally separate, you must have a registered name and password to send mail on each system you are using. You can have two different passwords, but it is advisable to use the same one because otherwise you will be prompted to log in again each time you switch systems. You can also call (LOGIN 'GV::) yourself to set your Grapevine log-in, and (LOGIN 'NS::) to set an NS log-in, apart from your default (Grapevine) log-in. Lafite Modes 1 When you use Lafite on the Grapevine system, Lafite is in Grapevine mode. When you use Lafite on the NS system, it is in NS mode. Mail sent to you on a particular system can be accessed, answered, and forwarded only if Lafite is in that system's mode. If you have loaded both NS and Grapevine protocol handlers (NS Mail and MailClient), Lafite needs to know which mode to operate in. The first time you start Lafite after loading a new Lafite or a full sysout, you must set the mode explicitly. Until you do this, the Lafite status window reads Mode Not Set. After that, Lafite starts up in the same mode it was in when you quit Lafite. To change modes after you have intialized Lafite, use the middle mouse button to choose Quit from the status menu. Another menu containing several options will appear; one is GV Mode and another is NS Mode. Select the mode you want with the left mouse button. The center region of your status window reflects the mode you select. If you are in Grapevine mode, it says Lafite (GV). If you are in NS mode, it says Lafite (NS). You can also find out what mode you are in by typing (LAFITEMODE) in your executive window, or change modes by typing (LAFITEMODE 'GV) or (LAFITEMODE 'NS). If you always want to start Lafite in the same mode, you can set the global variable LAFITEMODEDEFAULT to the value GV or NS, in which case Lafite will initialize itself in that mode. At sites with multiple Lafite modes, the values of the global variables LISPSUPPORT, LAFITESUPPORT, and TEDITSUPPORT are association lists in the form ((Mode1 ``Address1'') (Mode2 ``Address2'')---). Because the Lisp Report, Lafite Report, and TEdit Report forms are currently all sent to Grapevine addresses, they cannot be used at all in NS mode. From Grapevine to NS and Vice Versa 1 Without switching modes, you can send mail from a Grapevine to an NS address or vice versa through a mail gateway. The gateway provides pseudoregistries and pseudodomains for mail addressed to the other kind of network. (A list of the special registries and the domains they correspond to is stored on {Indigo}GV>GV-NS-Mapping.Txt.) A single message can contain both Grapevine and NS addresses. When Lafite is in Grapevine mode, you can send mail to the NS address Name:Domain:Organization by addressing it to ``Name:Domain:Organization''.NS (the double quotes are needed to keep the colon and any spaces in the name from being misparsed). For convenience, the domains PARC, OSBU North, and OSBU South can also be addressed as the registry of the same name, with the spaces removed. Thus, to send mail to Jones:PARC:Xerox, send it to Jones.PARC; to send mail to Oscar:OSBU North:Xerox, send it it Oscar.OSBUNorth. When Lafite is in NS mode you can send mail to the GV address Name.Registry by addressing it to Name.Registry:GV. For convenience, the registries PA and ES can be addressed directly as NS domains. Thus, to send mail to Jones.PA, send it to Jones:PA. Conversion of Grapevine Distribution Lists for NS Users. Until recently, people who used only NS mail could not add themselves to the many Grapevine public distribution lists. To address this problem, a new naming structure is being applied to general-interest public distribution lists in the PA, ES, and X registries. (Most organization and project lists, or any lists that might be used for access control, will not be converted to the new naming structure.) The new structure allows both NS and Grapevine mail users to add themselves to, broadcast to, and receive messages from these lists. Grapevine users will have to change the way they add themselves to lists. NS users will have to change both the way they send messages to lists that currently reside in Grapevine and the way they add themselves to lists. To enable the new distribution list structure, new NS domains have been established in a one-to-one correspondence with the ES, PA, and X Grapevine registries. ``All Areas:Xerox'' is the NS domain analogous to the X registry. ``PA Area:Xerox'' is the NS analog of the geographically based registry PA, and ``ES Area:Xerox'' is analogous to ES. After the restructuring is implemented for a distribution list in, for example, the X registry, Grapevine users will continue to broadcast to List^.X, but will add themselves to List-GV^.X. NS users will broadcast to List:All Areas, but will add themselves to List-NS:All Areas. Either form of broadcast will reach both the Grapevine members (List-GV^.X) and the NS members (List-NS:All Areas:Xerox). The conversion process will take several months. Distribution lists will be converted upon requests from their owners. If you own a distribution list and wish to request conversion, retrieve {USC:OSBU South:Xerox}DLRequest.Form, fill out the form, and send it to the appropriate address, according to the table below. Registry Grapevine User NS User 1 ES lists UserAdministration.ESArea UserAdministration:ES Area:Xerox PA lists UserAdministration.PAArea UserAdministration:PA Area:Xerox X lists UserAdministration.AllAreas UserAdministration:AllAreas:Xerox As soon as a distribution list of which you are a member is converted to the new naming structure, you will receive notice of the conversion. If you are a Grapevine member of List^.X, you will be added to List-GV^.X and removed from List^.X. If you are a Grapevine user and want to add yourself to a distribution list of which you are not currently a member, use Maintain to attempt to add yourself to List-GV^.X. If Maintain complains that this list does not exist, then add yourself to List^.X. You should continue to address messages to List^.X. If you are primarily an NS user and are a member of Grapevine List^.X, then when that distribution list is converted to the new structure, you will be moved to List-GV^.X. Then you should ask your system administrator to add you to List-NS:All Areas:Xerox. To make sure you don't miss any mail, wait three days after you start receiving two copies of messages sent to List^.X, then remove yourself from List-GV^.X with Maintain. To add yourself to a new distribution list, ask your system administrator to add you to List-NS:All Areas:Xerox. If this list does not exist, then add yourself to List^.X using Maintain. You should broadcast messages to List:All Areas:Xerox. One key point to remember is to never send messages to a list with a -GV or -NS suffix. If you do, you will not reach both NS and Grapevine members. Another key point is, never broadcast to both List^.X and List:AllAreas, or everybody will get two copies of the message. A more detailed description of the conversion process is filed on {USC:OSBU South:Xerox}DLConversion.Doc and {Indigo}GV>DLConversion.Doc. 2 Lafite-Related Lisp Users' Packages 1 As of this writing, Xerox employees have access to four Lafite-related Lisp Users' packages that have not yet been released to customers. The packages are Mailomat, Mail Sorter, Mail Cards, and Mail Reader. Mailomat enables you to automatically retrieve mail for one or multiple users for whom you have passwords. The program is filed on {Eris}Koto>LispUsers>Mailomat.DCOM; the documentation is on {Eris}Koto>LispUsers> Mailomat.TEdit. Mail Sorter will automatically sort mail into folders according to a set of rules you have specified. The code and documentation are on {QV}MailSorter.DCOM and {QV}MailSorter.TEdit, respectively. Mail Cards integrates the Note Cards environment with the Lafite mail system; you can place Lafite messages in specialized note cards, which are then placed in a Note Cards network. The code is stored on {QV}MailCards.DCOM and {QV}MailCardsLafiteInterface.DCOM; the documentation, on {QV}MailCards.TEdit. Lastly, the Mail Reader uses a voice synthesizer to read your mail to you over the telephone. You do not need special code to use this package, because you enter all commands by pressing the buttons on a touch-tone telephone. The Mail Reader's documentation is stored on {QV}Speech> MailReader>.MailReader.TEdit. All the abovementioned file names are subject to change. If you can't find a specific package, ask a release master or a network administrator for a pointer. 2 From Laurel to Lafite 1 Previous users of the Laurel mail program will find Lafite to have a similar user interface. Some of the ways in which it differs from Laurel are the following: Laurel can only access mail folders on the local disk; Lafite can access folders on remote file servers. Thus, it is not necessary to transfer mail folders back and forth between your local disk and your file servers. Laurel can only ``browse'' one mail folder at a time; Lafite can have several mail folders ``opened'' at the same time. Using the Interlisp window system, you can view the tables of contents of many mail folders and refer to messages in them independently. You may have multiple windows displaying messages and multiple windows for sending messages and you may move text freely among them. Messages can be selected in the table of contents by clicking anywhere within the summary line, unlike in Laurel, where you must select at the left end. The Browse Laurel File Command 1 Lafite can read mail files written by the Laurel and Hardy mail programs; the files it writes are in Laurel format. To browse a Laurel file that was produced by the Laurel mail reader version 6.1 or later, use the Browse Laurel File command from the middle-button Browse menu. Laurel 6.1 files are almost the same as Lafite files, but contain some line-formatting information that is stripped out by this command. After you have applied this command once to a file, you can subsequently browse the file with the normal Browse command (unless you use Laurel on it again, of course). This command is not intended for repeated use, but simply to make mail files built by Laurel more pleasing to browse. This command has the side effect of destroying any TEdit-formatted messages, so it should be used with care.(LIST ((PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC) STARTINGPAGE# 81) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD RIGHT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (270 12 288 36) NIL) (HEADING NIL (HEADINGTYPE FOOTINGR) (54 27 558 36) NIL) (TEXT NIL NIL (54 54 504 723) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD LEFT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (54 12 288 36) NIL) (HEADING NIL (HEADINGTYPE FOOTINGV) (54 27 558 36) NIL) (HEADING NIL (HEADINGTYPE VERSOHEAD) (54 762 558 36) NIL) (TEXT NIL NIL (54 54 504 684) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD RIGHT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (270 12 288 36) NIL) (HEADING NIL (HEADINGTYPE FOOTINGR) (54 27 558 36) NIL) (HEADING NIL (HEADINGTYPE RECTOHEAD) (54 762 558 36) NIL) (TEXT NIL NIL (54 54 504 684) NIL))))))2T)T( 1TTP1TT/  T.TT (.  .) +T)T)2T)T((f( )TB PAGEHEADING VERSOHEADB PAGEHEADING RECTOHEADA PAGEHEADINGFOOTINGVA PAGEHEADINGFOOTINGRMODERN +MODERN +MODERN MODERNMODERNMODERN + HRULE.GETFNMODERN + HRULE.GETFNMODERN + HRULE.GETFNMODERN + HRULE.GETFNMODERN + + + + HRULE.GETFNMODERN  HRULE.GETFNMODERN HRULE.GETFNMODERNn  HRULE.GETFNMODERN *  HRULE.GETFNMODERN Oc  HRULE.GETFNMODERN +, Z g Z - $ 7 * % - ) & 7 6 ) * - M * ' @ J  HRULE.GETFNMODERN +.b) !  HRULE.GETFNMODERN +W%) / HRULE.GETFNMODERN +:  HRULE.GETFNMODERN   HRULE.GETFNMODERN +  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +J  HRULE.GETFNMODERN +p/ 5 MQ  HRULE.GETFNMODERN + Ed  HRULE.GETFNMODERN +s  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +o  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +  HRULE.GETFNMODERN +{  HRULE.GETFNMODERN HRULE.GETFNMODERN  HRULE.GETFNMODERN  % HRULE.GETFNMODERN e (E|>:!#&OM" HRULE.GETFNMODERN +DDGR0>^DnG6< HRULE.GETFNMODERN$ HRULE.GETFNMODERN  HRULE.GETFNMODERN HRULE.GETFNMODERN>S  HRULE.GETFNMODERN tuKz \ No newline at end of file diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-GLOSSARYCUSTOMER.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-GLOSSARYCUSTOMER.TEDIT new file mode 100644 index 00000000..f3b4f472 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-GLOSSARYCUSTOMER.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-GLOSSARYINTERNAL.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-GLOSSARYINTERNAL.TEDIT new file mode 100644 index 00000000..8e03b4df Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-GLOSSARYINTERNAL.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-INDEXCUSTOMER.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-INDEXCUSTOMER.TEDIT new file mode 100644 index 00000000..ea317c03 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-INDEXCUSTOMER.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-INDEXINTERNAL.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-INDEXINTERNAL.TEDIT new file mode 100644 index 00000000..50ece688 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-INDEXINTERNAL.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-QUICKREFERENCECUSTOMER.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-QUICKREFERENCECUSTOMER.TEDIT new file mode 100644 index 00000000..7893c547 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-QUICKREFERENCECUSTOMER.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-QUICKREFERENCEINTERNAL.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-QUICKREFERENCEINTERNAL.TEDIT new file mode 100644 index 00000000..3ca80d7f Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-QUICKREFERENCEINTERNAL.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-SEC1.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC1.TEDIT new file mode 100644 index 00000000..6fff5536 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC1.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-SEC10.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC10.TEDIT new file mode 100644 index 00000000..22f70da2 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC10.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-SEC11.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC11.TEDIT new file mode 100644 index 00000000..c7218a29 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC11.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-SEC11BLANKPAGE.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC11BLANKPAGE.TEDIT new file mode 100644 index 00000000..14048e58 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC11BLANKPAGE.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-SEC12.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC12.TEDIT new file mode 100644 index 00000000..6ef092e0 Binary files /dev/null and b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC12.TEDIT differ diff --git a/library/lafite/docs/users-guide/LAFITEMANUAL-SEC13.TEDIT b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC13.TEDIT new file mode 100644 index 00000000..4992d76e --- /dev/null +++ b/library/lafite/docs/users-guide/LAFITEMANUAL-SEC13.TEDIT @@ -0,0 +1,14 @@ +1 A USER'S GUIDE TO LAFITE 1 A USER'S GUIDE TO LAFITE CUSTOMIZING LAFITE 1 CUSTOMIZING LAFITE 1 13. CUSTOMIZING LAFITE 6 Some aspects of Lafite's behavior, such as whether each message of a batch you print starts on a new page and how many messages are shown in your out-box, are controlled by global variables set in your intialization file. Each variable is set to a default value that most users have found acceptable. However, you may want to reset some global variables to tailor Lafite to your needs. You edit Lafite variables in the same way as any other part of your intialization file, by typing (DC INIT) to bring up a DEdit window on your initialization file, resetting the variables, then typing (MAKEFILE '{FILESERVER} INITFILENAME) to save the new version of your initialization file. For detailed information on DEdit and the MAKEFILE function, see the Interlisp-D Reference Manual. 2 Lafite's Global Variables 1 LAFITEDEFAULTHOST&DIR [Variable] is the directory on which Lafite looks for the LAFITE.PROFILE and all mail folders and message forms you access if you don't supply an explicit directory. Lafite uses its own host and directory names for mail folders, etc., rather than the current connected directory because you may want to keep your mail folders someplace special (e.g., the local disk or your log-in directory), and the connected directory can change. LAFITEDEFAULTHOST&DIR is provided to tell Lafite where you usually keep your mail. LAFITEDEFAULTHOST&DIR should be in the same form as the variable LOGINHOST/DIR (i.e., {FILESERVER}). If LAFITEDEFAULTHOST&DIR is NIL, then the value of LOGINHOST/DIR is usedi.e., your log-in host and directory. LAFITEFORMDIRECTORIES [Variable] is a search path for Lafite forms, initially NIL. When you choose the Saved Form command underneath Send Mail, the form name that you enter is first searched for on your default directory (LAFITEDEFAULTHOST&DIR), and if it is not found there, Lafite searches the directories in the list LAFITEFORMDIRECTORIES. LAFITEFORMDIRECTORIES is typically set to a list of one or more public directories on which generally useful forms have been collected. LAFITESTATUSWINDOWPOSITION [Variable] specifies where the status window appears when Lafite is invoked. It is a POSITION or NIL (in which case you are asked to specify a position when Lafite starts). LAFITEBROWSERREGION [Variable] is a REGION used to describe where the primary (i.e., first) browser window is to be placed on the screen. Initially, it is set to something reasonable'' for the standard initial display configuration. If you set it to NIL, you are prompted to specify a region the first time any such window is created. LAFITEDISPLAYREGION [Variable] is a REGION used to describe where the primary (i.e., first) message display window is to be placed on the screen. Initially, it is set to something reasonable'' for the standard initial display configuration. If you set it to NIL, you are prompted to specify a region the first time any such window is created. LAFITEEDITORREGION [Variable] is a REGION used to describe where the primary (i.e., first) message composition window is to be placed on the screen. Initially, it is set to something ``reasonable'' for the standard initial display configuration. If you set it to NIL, you are prompted to specify a region the first time any such window is created. DEFAULTMAILFOLDERNAME's [Variable] value is used if no mail folder is supplied to the function LAFITE, i.e., you call (LAFITE 'ON). Initially, this value is ACTIVE.MAIL. LAFITEMAIL.EXT [Variable] is the default extension for names of mail folders. It is initially MAIL. LAFITETOC.EXT [Variable] is the string appended to the name of a mail folder to produce the name of its table-of-contents file. It is initially LAFITE-TOC. LAFITEFORM.EXT [Variable] is the default extension for the names of user-defined form files. It is initially LAFITE-FORM. LISPSUPPORT [Variable] specifies the address to which Lisp Report messages are sent. Its value is a single string containing one or more addresses, all in the form you would put in the To line of a message header. If LISPSUPPORT is NIL, then the Lisp Report form cannot be used. It is initially NIL. Site administrators may want to set this variable in their site initialization files to the mail address of their local Lisp Support. LAFITESUPPORT [Variable] specifies the address to which Lafite Report messages are sent. Its value is a single string containing one or more addresses, all in the form you would put in the To line of a message header. If LAFITESUPPORT is NIL, then the Lafite Report form cannot be used. It is initially NIL. Site administrators may want to set this variable in their site initialization files to the mail address of their local Lafite Support. TEDITSUPPORT [Variable] specifies the address to which TEdit Report messages are sent. Its value is a single string containing one or more addresses, all in the form you would put in the To line of a message header. If TEDITSUPPORT is NIL, then the TEdit Report form cannot be used. It is initially NIL. Site administrators may want to set this variable in their site initialization files to the mail address of their local TEdit Support. LAFITEDISPLAYFONT [Variable] is a font used for displaying messages. You may change it without changing the other Lafite fonts. It should be a FONTDESCRIPTOR as returned by FONTCREATE. In your initialization file, this is usually specified with a FONTCREATE expression, e.g., (VARS (LAFITEDISPLAYFONT (FONTCREATE 'MODERN12))). Initially, it is Times Roman 12. LAFITEEDITORFONT [Variable] is a font used for composing messages. You may change it without changing the other Lafite fonts. It should be a FONTDESCRIPTOR as returned by FONTCREATE. Initially, it is Times Roman 12. LAFITEHARDCOPYFONT [Variable] is a font used for printing messages. You may change it without changing the other Lafite fonts. It should be a FONTDESCRIPTOR as returned by FONTCREATE. Initially, it is Times Roman 12, which prints as Classic 12 on an Interpress printer. LAFITEBROWSERFONT [Variable] is the font used for displaying the table of contents in the browser window. It is initially Gacha 10. LAFITEMENUFONT [Variable] is the font used for the items in all Lafite menus. It is initially Helvetica 10 Bold. LAFITETITLEFONT [Variable] is the font used for the title bar (``Lafite'') in the Lafite status window. It is initially Helvetica 12 Bold. LAFITEENDOFMESSAGEFONT [Variable] is the font in which the LAFITEENDOFMESSAGESTR is displayed (see below). It is initially Times Roman 10 Italic. LAFITEENDOFMESSAGESTR [Variable] is a string containing the text of the End of Message token displayed at the end of a message. If LAFITEENDOFMESSAGESTR is NIL, then no ``End of Message'' token appears. LAFITENEWPAGEFLG [Variable] is initially T. If so, the Hardcopy command starts each message on a new page. Otherwise it separates each message by a line of dashes. LAFITEHARDCOPYBATCHFLG [Variable] allows you to postpone printing messages until several can be done at once. Printing several messages at once helps to keep your short messages from being lost amongst other users' long output, saves paper, and saves time because you don't have to wait for individual messages to be formatted for printing. When LAFITEHARDCOPYBATCHFLG is T, Lafite batches your hard-copy requests. It doesn't actually print the messages until you do an Update, at which point Lafite sends them all to the printer in one batch. When you have hard copy pending, the Hardcopy command is speckled to remind you of this fact. The Update command has an additional choice, Do Hardcopy Only, in case you want to get your batched hard copy printed without doing an actual Update. When batching hard copy, LAFITENEWPAGEFLG applies only to the messages selected at each Hardcopy invocation; each new set of messages starts on a new page, independent of the setting of LAFITENEWPAGEFLG. LAFITEHARDCOPYBATCHFLG is initially NIL. LAFITEHARDCOPY.MIN.TOC [Variable] is a positive number if non-NIL. Whenever Lafite is instructed to produce hard copy for more than LAFITEHARDCOPY.MIN.TOC messages, it also produces a table of contents as a cover page for the hard copy. Currently, this flag is noticed only if LAFITEHARDCOPYBATCHFLG is NIL. It is initially NIL. MAILWATCHWAITTIME [Variable] is the number of minutes between polling for new mail from your mail servers. It is initially set to five. LAFITEFLUSHMAILFLG [Variable] is initially T. If it is NIL, Lafite won't flush your in-box when retrieving new mail, so the mail will still be there when you invoke Get Mail again. LAFITEIFFROMMETHENSEENFLG [Variable] makes sure, if T, that messages sent from you are considered ``seen'' (and hence do not have the question mark), even though you have not yet displayed them. It is initially T. LAFITEDISPLAYAFTERDELETEFLG [Variable] can be set to T or ALWAYS. If T, Lafite displays the next message if you delete the message in the message display window and the next message is undeleted and unexamined (i.e., it is marked with a question mark). If ALWAYS, Lafite displays the next undeleted message even if it has already been seen. It is initially T. LAFITEMOVETOCONFIRMFLG [Variable] controls whether Lafite requires confirmation of the Move To command. If ALWAYS, all moves require confirmation; if LEFT, then only left-button moves (selecting the destination from a menu) require confirmation; if MIDDLE, then only middle-button moves (using the default Move To folder) require confirmation; if NIL, then no moves require confirmation. It is initially ALWAYS. LAFITEBUFFERSIZE [Variable] is the number of 512-character buffers used by the stream managing the file behind an open browser window. If you regularly receive very long messages, you might want to increase this to improve performance of Display followed by Hardcopy or Move To. Initially 20, which handles messages up to about 10,000 characters long. LAFITEOUTBOXSIZE [Variable] specifies the number of delivered messages to be retained in your out-box. As you send more messages, older ones fall off the end. Increasing this number gives you a longer ``history'' from which you can select and reedit old messages, but the desire for a longer history should be balanced with the knowledge that you are tying down the resources used by each of those messages. Setting LAFITEOUTBOXSIZE to zero or NIL disables the out-box feature: after delivery, messages completely vanish. LAFITEOUTBOXSIZE is initially two. LAFITENEWMAILTUNE [Variable] is a list of the form acceptable to the function PLAYTUNE or NIL, in which case it is ignored. It is played when Lafite discovers you have new mail waiting. LAFITEGETMAILTUNE [Variable] is a list of the form acceptable to the function PLAYTUNE or NIL, in which case it is ignored. It is played when a Get Mail command completes. 2 How to Add a New Message Form to Lafite 1 The normal way to add a new message form to Lafite is to edit an existing form (or build one from scratch) and save it using the Save Form menu item (see chapter 9, ``Writing Messages''). However, you can also provide message forms that compute the text at the time you request the form, as, for example, the Lisp Report does. To add your own items to the Message Forms menu, add a standard three-element menu item to the variable LAFITESPECIALFORMS and then set the variable LAFITEFORMSMENU to NIL (this is where the menu is cached). The three-element menu item should yield a LITATOM as its ``value,'' that atom being interpreted as follows: 1. If the atom has a function definition, the function is called (with no arguments) and the returned value (a string or a TEdit text stream) is used. 2. If the atom has a value, its value (a string or a TEdit text stream) is used. 3. Otherwise, a copy of the file by that name is used. For example, if you wanted to add a message form that contained the date the user's version of TEdit was made (as in the TEdit Report form), you could add (``TEdit Support'' (QUOTE MAKETEDITFORM) ``Make a form to report a problem with TEdit'') to LAFITESPECIALFORMS; MAKETEDITFORM could be defined to be [LAMBDA NIL (PROG (OUTSTREAM) (SETQ OUTSTREAM (OPENTEXTSTREAM `` '')) (printout OUTSTREAM ``Subject: TEdit: >>Subject<<'' T) (printout OUTSTREAM ``To: '' TEDITSUPPORT T) (printout OUTSTREAM ``cc: '' (USERNAME T) (printout OUTSTREAM ``TEdit-System-Date:" TEDITSYSTEMDATE T T) (printout OUTSTREAM ``>>Message<<'' T) (RETURN OUTSTREAM] where TEDITSUPPORT and TEDITSYSTEMDATE are variables set by TEdit. Lafite supplies one function to make this kind of message form easier to construct. (MAKEXXXSUPPORTFORM 'SYSTEMNAME 'ADDRESS 'SYSTEMDATE) [Function] creates a message form (a TEdit stream) to be mailed to the maintainers of SYSTEMNAME. SYSTEMNAME is the name of the subsystem (a string); SYSTEMDATE, if non-NIL, is a date (string) of importance to include in the message; and ADDRESS is the mail system address of the intended recipient(s) or an association list in the same form as the variable LISPSUPPORT. If the ADDRESS is NIL, MAKEXXXSUPPORTFORM prints a message in the prompt window that the form is not supported, and returns NIL. For example, MAKETEDITFORM is actually defined as [LAMBDA NIL (MAKEXXXSUPPORTFORM ``TEdit'' TEDITSUPPORT TEDITSYSTEMDATE)] and selecting TEdit Report in the Message Forms menu produces a form like the one in figure 29. U +??00000000000000000000???000~0c3 0c<88x >0cf6 0c~ٳ>8x 0000???>}>s19hο>smm;m?>sm>mm>یc8l???00000 0`?0 D! ߻0.D xﻼzcfzg>="?zaǦp0D11"@" [wqط{^w00D!@> ;{ߝ{w0D!@" {]{w0D!@  w{{wp0N""@@ $ۻv;ݝ{{0p4qqH00P0`000000BB0@0@\.0!D#Aq!:@80!|!@`B!!@0!D!@B!!@0!@!BB!!@0!AKd2!H0| 2hX,820@ 0@ 0p8000008000pq瀸p0"B Ĉ0F!0)Ahh0)A0 @Ș0qa00000000000000000000000!0?ax8 0@ 0@@@@ D``0 08@ #  0c"DA $D`X!! 0!` CG $8" 0!P4B@ $0!P"DB@ $ 0"q !"HLI@DD BB 0|?!v0<| 0@ 000000 0 q0@# @@D88" 0@!!xp#AD !0@bN  ̀$DB ! 0@" ! ?Bǀ @0@!  !#D B@@ 0A D !!$D B@@!0B"F@1$DđH@@H@"0s.qc|A@>>!0 0000000p 0@ A0`@0@0`ł8X:? P?0QB$FF9DFN@  @0Q@dB DB?D@ !@0JAB4DB D@ @@@!@0JB$BDDB D@ @0DBdDBLD'D@! " "@0;v9ǎ""00000000q0`"" 0`xx8pg@ 0QC: D!1 @. 0QA #1 @0JA B! 0JA B!!0DAD !!"08xph88@>10@0 000000p???0`!!!0`f w|8@0QA"LDD@,0QC"0JB0JBD 0DADDD!0㻏|8@0P@0`000000 |0A  0@,p8X<@$ ;Xxp `0DtDDD@$$ 200|!D@DB D!"0D!D@(~U +D!"0@!D@(U +D!"0@ DDD"$D$"H!0pphh88@ Ü"8|qw8a0ø0@(@00 00000 0 p0 80@A@`0`0Af <@@8p`p@X