Zmail and mail composition in Symbolics Genera

User-interface substrate and CLIM boundary

Zmail is built from ZWEI editing streams and the TV window system. Genera 8.5 also uses selected Dynamic Windows and Command Processor services for typed items such as paths, addresses, sequences, drafts, and calendar objects. The active summary rows are an older TV scroll-window path: they emit SUMMARY-MOUSE blips. A proposed conversion of those rows to Dynamic Windows presentations survives only in commented source and is not active behavior in this profile.

The Zmail system declaration has no CLIM dependency, and the inspected source defines neither a CLIM application frame nor a CLIM port. A reimplementation may use CLIM internally, but the historical substrate described here is ZWEI + TV + selected Dynamic Windows/Command Processor facilities, not CLIM.

One frame, two Zmail processes

The manual says Zmail has one main window and foreground and background processes. The 8.5 source agrees. Frame initialization constructs the panes and creates one process named Zmail background; selection code reuses the existing main frame, moves it to a usable screen when necessary, and reconstructs it only when the old object cannot be selected. Startup is restricted to the main console rather than arbitrary remote terminals.

The foreground command loop owns interactive state and consumes both user input and responses sent through a dedicated background I/O buffer. The background process handles queued file work, preloading, parsing, saving, and exposed-frame mail checks. This design lets long mail-file operations yield without making the interactive command loop itself the storage worker.

Ordinary background requests are pushed onto the front of their queue and read from the front, so they run last-in, first-out despite a nearby source comment calling the queue FIFO. Preload requests alone are appended and therefore remain FIFO. Loading admits at most 20 messages per quantum; saving and parsing admit at most 10 each.

Messages, buffers, sequences, filters, and universes

Zmail's working objects form several layers:

• a message carries header and body intervals, attributes, keywords, parse state, file provenance, references, and transmission state;
• a mail buffer associates messages with a storage representation or a temporary collection;
• a sequence is an ordered selection with a current message, movement state, and point stack;
• a filter selects messages by attributes, headers, keywords, dates, and other predicates;
• a universe supplies a wider search space spanning buffers and collections;
• reference operations treat message identifiers and reply chains as conversations.

The user-facing result is that Delete, Keywords, Move, Sort, Survey, Map Over, and conversation operations are not merely text edits. They update message and collection state, which is then persisted according to the active mail-file format.

The Genera parse-state slot is not a simple Boolean. NIL means to use the owning buffer as format provenance; a message-buffer object names a specific provenance; T means successfully parsed; :KILLED means dead or errored unless a caller explicitly permits it; and an SI:PROCESS object owns a parse in progress while competing callers wait. Failure restores the prior NIL or buffer provenance rather than publishing T. A clone that collapses these states loses both parse ownership and the killed-message failure boundary.

Panes and configurations

The release defines panes for the summary, displayed message, headers, outgoing mail text, mode line, minibuffer, filter and universe controls, profile editor, ordinary and filtering command menus, and calendar views. Public configurations include Summary only, Both, two distinct entries whose visible label is Message only, Filtering commands, Summary/Message toggle, Send, Calendar, Month, Four weeks, Week, and Year. One Message only entry is the ordinary message layout; the other omits the command menu. The duplicate label is historical behavior, not a documentation typo. Internal reply, filter, universe, and profile layouts support particular command states.

The normal initial view is Both: summary above, command menu in the middle, and message below. Summary rows are interactive TV SUMMARY-MOUSE blips, not Dynamic Windows presentations. Left selects a row; middle applies a profile-selected operation such as delete/undelete; right opens a conditional message menu. The exact menu and binding surfaces are in the companion reference.

Reading and navigating mail

• load an inbox, check for new mail, select or examine mail files, and maintain several loaded buffers;
• move by ordinary, undeleted, unseen, and recent messages, with first/last variants and a message point stack;
• switch between summary-only, message-only, combined, filtering, and calendar views;
• search for strings, list occurrences, jump to messages, show a message or an entire selection, and survey compact summaries;
• display and explain headers, routing paths, references, mailing lists, file references, and address-directory information.

Organizing and transforming messages

• delete, undelete, temporarily remove, expunge, concatenate, move, rename, and reverse sequences;
• assign and remove keywords, edit the keyword list, and merge keywords across a conversation;
• define filters and universes, mark survey results, select temporary collections, and apply Map Over operations to a selection;
• sort messages and identify or remove duplicates;
• select, append, move, delete, compare, survey, or merge by reference chain;
• construct or split digests, reformat or restore headers, and run rules over a message or a collection.

Composing and sending

• compose new mail, replies, forwarded mail, redistributed mail, redirected mail, bug reports, and local mail;
• choose one-, two-, or zero-window reply layouts and optionally yank the original message;
• add To, Cc, Bcc, Fcc, blind Fcc, Subject, From, Reply-To, In-Reply-To, References, File-References, Start-Date, and Expiration-Date fields;
• continue, save, restore, write, revoke, inspect, or preserve draft messages;
• use templates, mailing-list expansion, address motion, file references, character styles, and optional text encryption;
• compose and survey reminders in calendar mode;
• invoke the source command family named ECO. The source examined here does not establish a safe expansion of that acronym, so none is asserted.

Profiles, Help, and customization

The profile editor groups options for reading and checking mail, saving, sending, replies and forwarding, window configuration, keywords, mail-file format, collection behavior, reminders, destructive-command confirmation, summary mouse behavior, and background work. Several menu commands use the profile's middle-button choice, next/previous policy, reply layout, pruning policy, and draft-ending policy rather than a fixed global rule.

The selected sources contain 81 textual user-option forms: 80 active declarations and one declaration inside a block comment. The inactive form is evidence of an older path, not a runtime registration. The semantic companion records every form's type, default, restriction, persistence and derived update behavior, plus the exact filter and universe definition languages and Profile save/compile/reset order.

Zmail has its own Help, key self-documentation, Apropos, Describe Command, and extended-command reader. The command registry is populated when source files load and is mutable by patches, site files, profiles, and Set Key. The 152 command names in the companion are therefore a clean-release denominator, not a promise that every configured site exposes an identical live registry.

Calendar and reminders are message views

Calendar is not a separate appointment database. It projects ordinary Zmail messages whose parsed headers contain a Reminder-period or Start-date, optionally constrained by Expiration-date and Reminder-time. Every present constraint must pass and Period or Start must exist. Expiration is strict at the selected day's midnight. Start is tested only against the end of that day, so a start-only reminder continues to appear on later days unless another header limits it. Period expressions are expanded through the Time subsystem and cached with parsed header state.

The source supplies Year, Month, Four Weeks, and Week frames. Year arranges twelve month panes in three rows of four and can XOR-highlight dates containing reminders; that highlighting is disabled by default. Month chooses a four-, five-, or six-row grid, Four Weeks fixes four rows, and Week shows seven day panes. Monday is the default first weekday. Day panes place holidays first, then stable-sort reminders by explicit time; the current message is bold with an arrow and holidays are italic.

The Calendar command surface includes setting Start and Expiration on the current message, composing once-only or periodic reminders, adding a reminder from a selected day, and surveying a date. Dynamic Windows exposes Day, Month, and Week-containing-day presentations plus conversions from Day to midnight universal time and to a date-only reminder value. Calendar contributes five of Zmail's 37 presentation-to-editor-command translators.

An exact historical asymmetry is preserved in the D08 specification: changing the Sunday/Monday option through the ordinary profile update recomputes Year, Month, and Four Weeks but omits an already displayed Week. The separate full recompute path includes Week. These source-derived populated layouts have not yet been exercised in the preserved 8.5 world, so their visual appearance remains an explicit runtime oracle rather than a guessed screenshot.

Integrated Zmail composition

Mail, Reply, Forward, Redistribute, Redirect, Continue, and recursive composition create a Zmail draft and switch the frame to a Send or reply configuration. The header and body regions are Zwei intervals, so ordinary editing commands are inherited. Zmail adds mail-header movement, header-field insertion, draft, reply-layout, send/abort, original-message yanking, encryption, file-reference, and mailing-list commands.

End is policy-sensitive in the reply editor: the configured profile can send, offer both send choices, return to adding text, or offer both text choices. Control-Altmode sends directly. The right-button draft menu and the extended command list deliberately share the same command array except that Show Expanded Mailing List is extended-command-only.

Zwei Mail mode in Zmacs

Zmacs Control-X M calls a separate command in zwei/mail.lisp. It selects a special Mail buffer, initializes Text mode, and turns on the Mail minor mode. A new draft contains To and Subject fields plus a body separator. End and Control-Altmode transmit; Abort, Control-Z, and Control-] quit without transmitting; Meta-Help shows a patch-mail example; and its editor menu adds Add File References.

This mode depends on Zmail: if the Zmail window variable is not bound, its source rejects sending rather than implementing an independent transport. It also has source-visible behavior not prominent in the public Zmail narrative:

• a nonzero numeric argument requests the most recently selected Mail buffer;
• zero displays existing Mail and bug-mail-frame drafts for selection;
• abort from a standalone mail frame can preserve the draft as a Zmacs buffer;
• retransmitting a previously sent draft can add Supersedes and Comments according to the shared Zmail option;
• sent Mail and bug-mail-frame buffers are deliberately retained rather than marked reusable.

The release also supplies a standalone top-level mail editor used by the Lisp MAIL entry point. It is another view over the same Zwei Mail-mode and Zmail sending boundary, not a separate mail transport.

Reader entry and menus

Select M exposed a live Zmail frame with the documented summary, 20-item main command menu, message pane, and mode line. Because the preserved world began as CL-USER, Zmail required login. Selecting the offered local LISP-MACHINE user and accepting empty keywords completed that login. Zmail then displayed concise instructions for Help, Get inbox, Mail, and bug mail, and the mode line reported no current message sequence.

Mouse-R in the message pane displayed all 21 source-defined auxiliary actions, from conversation selection through mailing-list display. This verifies that the source menu is active in this world, not merely left in a dormant file.

Site boundary on integrated composition

Clicking Mail did not send anything. It immediately entered an error handler because the expected file host DIS-SYS-HOST was unavailable for file operations. Returning to Zmail restored the top-level frame. This establishes a site-configuration dependency in the preserved world; it does not establish a defect in a configured Genera site, and the museum harness must not supply or guess that missing service.

Live Zwei Mail mode

Select E, then Control-X M, successfully opened *Mail-1* in Zmacs (Text Mail). The visible buffer contained To and Subject fields and the expected body separator; the mode line described End as transmit and Abort as quit. No recipient or body was entered.

The generic harness Abort alias mapped to an unintended editor operation in this context. Control-], one of the source-defined Mail-mode quit bindings, returned to Fundamental mode. The editor then told the user that a numeric argument to Control-X M could continue. A subsequent Control-U 1 Control-X M probe displayed a fresh *Mail-2* rather than proving reselection of *Mail-1*. The source semantics are clear, but the exact prefix/retained-buffer runtime path remains a TODO rather than being “confirmed” from this ambiguous probe.

Published runtime screenshots

Two representative captures passed the image- and use-specific review in the screenshot publication policy. They establish two different application surfaces without publishing a message, recipient, address book, mailbox, or substantial Help prose.

The reader capture shows the one-frame Zmail organization after local login. The short hints are retained because they identify what the otherwise empty panes and menu are for; the image is not evidence about populated-message rendering.

The second capture is deliberately blank. Its documentary purpose is to prove that Control-X M creates a Zwei editing surface with a mail template and a distinct mode line, rather than selecting the full Zmail reader. Residual Zmail pixels and the dithered area at the right are incidental state from the surrounding display; they do not specify the standalone editor's frame geometry.

The exact raw-to-curated mappings, image identities, action prefixes, session record, shutdown result, and publication limits are recorded in the curated Genera screenshot catalog. No other image from this session is approved by implication.

The ignored run record is 25,641 bytes, SHA-256 70612937b74496027fb1981586dbd11dd8651fd786fdedd394d20a158c94747c. The 46-record action log is 22,038 bytes, SHA-256 2a65002bf6dcf12b12fb5e364b8aeca652f90b83b1270677687c7c5c3785db72. The shutdown prompt was observed, yes was sent and accepted, and cleanup progress appeared. The known cold-load mutex stall then required bounded host cleanup. Final status is forced-stopped with forced_stop=true, forced_after_confirmed_shutdown_stall=true, orderly_vlm_host_shutdown=false, and state_may_be_incomplete=true. The harness itself did not invoke Save World and did not create a host-process checkpoint. The separately recorded save_world_performed and guest_checkpoint_created fields remain unknown because the guest input was not independently audited for either event. The private world remained byte-identical to the base; that unchanged hash is not by itself proof about either field. The record marks unsaved_lisp_state_discarded=true; this means only that unsaved guest state was lost when the bounded cleanup ended the VLM, because the harness has no host-process resume mechanism. Supervisor, Xvfb, and VLM processes were all absent after stop.