Symbolics Genera Dynamic Windows reimplementation specification

Section evidence map

This map is the evidence key for the normative sections below. Line spans refer to the exact licensed witnesses in Artifact identities. They are portable artifact-relative paths, not machine paths. G85-SRC establishes selected source behavior; it does not prove that every definition is the one currently patched into the running world.

The manual corroborates the public model but omits several source-visible rules: the four-state internal subtype result, attempted handler name/package tie-break and its apparent source typo, semantic blips in the input buffer, redisplay's collection/display identity check, the seventh standard TREE-BROWSER pane, and several failure-recovery paths. Conversely, a source-only branch remains labeled TODO-RUNTIME until a harmless synthetic oracle reaches it.

TV

TV supplies screens, sheets, raster operations, stream primitives, windows, mouse routing, menus, frames, color, and graphics foundations. Selected Dynamic Windows graphics and flavor mixins load during TV construction in the inspected release. This is a boot dependency, not evidence that TV and Dynamic Windows are the same system.

PRESENTATION-SUBSTRATE

The substrate owns type descriptors and methods, type definition, handler definition, histories, standard types, completion, typed acceptance, input contexts, and handler matching. It MUST be usable without the full program-framework layer.

CP

The Command Processor owns command tables and the command reader/executor. It uses presentation input and can be embedded in Dynamic Window programs, while remaining a separate command-language subsystem.

DYNAMIC-WINDOWS

The core adds formatted output, redisplay, box arithmetic, displayed-presentation records, Dynamic Window streams, viewport graphics, window combinations, graphing, color, and binary graphics.

DYNAMIC-WINDOW-CLIENTS

The client layer adds framework panes, DEFINE-PROGRAM-FRAMEWORK, Accepting Values, queries, and sequence-reordering utilities. Loading a client MUST NOT redefine the meaning of core presentation matching.

Domain object

A domain object is application-owned state. Dynamic Windows MUST NOT require it to inherit from a UI class, contain a screen rectangle, or retain callbacks. Object identity MUST be preserved when a presentation is selected; reparsing printed text is only one alternate input path.

Presentation type specifier

PresentationTypeSpecifier {
  type_name
  data_arguments
  presentation_arguments
  meta_options
}

Data arguments refine semantic membership and subtype relationships. Presentation arguments control parsing, printing, view, prompts, defaulting, or other interaction without necessarily changing the accepted object set. Meta options are interpreted by the substrate rather than the type's membership predicate.

The implementation MUST retain the complete specifier through parsing, output, handler lookup, and diagnostics. It MUST NOT reduce every presentation type to a host language class.

Type descriptor

PresentationTypeDescriptor {
  name
  lambda_lists_for_data_and_presentation_arguments
  pretty_name_and_obsolete_state
  inheritance_generators_and_equivalent_types
  printer_parser_and_type_description_methods
  views_and_default_view_methods
  default_and_input_history_methods
  highlighting_choose_menu_and_accept_values_displayers
  subtype_supertype_walk_and_membership_operations
  lisp_type_or_membership_predicate
  cache_key_generators_and_cache_policy
  optional_binary_graphics_method
  protocol_flags_and_version
  definition_generation
}

A descriptor can provide printer, parser, type-name printer, describer, input-history policy, default preprocessing, postprocessing, highlighting-box computation, menu and Accepting Values displayers, views, subtype walking/predicates, equivalent host type, and binary-graphics encoding. Methods can be inherited or obtained through type expansion. (G85-SRC, G8-MAN)

G85-SRC establishes mutable descriptors, definition generations, and dependent caches. The following publication rule is INFERRED: readers MUST see the old complete descriptor or the new complete descriptor, never a partially installed method set. Completing a definition advances its generation and invalidates affected method, subtype, common-supertype, type-key, and handler caches. A replacement MAY use immutable descriptor snapshots rather than reproducing Genera's mutable representation.

Displayed presentation

DisplayedPresentation {
  object_or_locator
  source_form_or_location
  type_specifier
  view
  region_or_bounding_box
  parent: DisplayedPresentation | OutputRecord | null
  children
  sensitivity_policy
  highlight_policy
  stream_and_history_identity
  rendering_record_or_replay
  metadata
  liveness_state
}

The record MUST connect the exact object to its visible representation. Presentations may nest. A parent can share a highlighting region with children, allow or suppress sensitive inferiors, or present the same pixels at another semantic level. A record can remain in output history after scrolling out of the viewport, but it is pointer eligible only when its transformed region is currently visible.

The semantic object can be stored directly, recovered from an application location, or recomputed from a recorded form under the selected protocol. No output record may retain a dead stack/ephemeral reference after its dynamic extent. A null presentation marks deliberately nonsensitive output. A parent region can contain holes occupied by children, and a graphics presentation can refine rectangular hit testing by shape and priority/timestamp.

Input context entry

InputContextEntry {
  required_type_specifier
  superior_context_or_null
  throw_or_return_enabled
  options
  context_generation
}

Input contexts form a dynamic stack. The innermost active context gets the first opportunity to consume matching input. Compound parsers can push subordinate contexts while accepting components. A reduced context MAY add a predicate or transform but MUST retain enough ancestry for matching and diagnostics.

Entering a context MUST install its input-editor, mouse-motion wakeup, input-wait, and dynamic-blip behavior as required by the stream. Leaving it MUST announce the context change and remove transient highlighting and documentation in unwind-protected cleanup, including after Abort or an error.

Presentation blip and input-editor state

Pointer input is carried through the stream as a semantic blip rather than converted to display text:

PresentationBlip {
  presentation_or_semantic_result
  presentation_type
  triggering_raw_and_logical_gesture
  selected_handler
  object
  options_and_provenance
}

InputEditorState {
  buffer_elements              // characters, style changes, semantic blips
  point_and_optional_mark
  activation_and_rescan_state  // none, end-of-line, or activation
  per_stream_input_history
  shared_kill_ring_and_index
  numeric_argument
  command_map
  pending_static_blips
  dynamic_blip_handlers
  echo_and_display_state
}

The editor displays a compact placeholder for a presentation blip but MUST return the semantic element on rescan. Ordinary movement and deletion treat it atomically. An old blip whose presentation has been deleted MUST signal a controlled dead-blip condition; it must not dereference stale output history.

Handler descriptor

PresentationHandler {
  kind: translator | action | presentation_to_command | command_menu | blank_area
  stable_name
  source_type
  target_type
  context_type
  logical_gesture_set
  object_tester
  context_or_result_tester
  translation_or_action_function
  priority
  documentation_and_pointer_documentation
  menu_policy
  highlight_policy
  context_independent
  exclude_other_handlers
  blank_area_enabled
  definition_generation
}

A handler is selected by semantic types and active context, not installed directly on one rectangle. The same handler can apply to every visible object of a type; the same object can have different applicable handlers in different contexts.

An action is a noncomposing translator whose useful result is its side effect and which normally resumes the original accept operation. A presentation-to-command translator targets the semantic command type. Blank-area handlers use a no-type source sentinel and are considered only when no presentation owns the location.

Output and redisplay records

OutputRecord {
  kind
  region
  children
  replay_or_renderer
  parent
}

RedisplayPiece extends OutputRecord {
  unique_id
  cache_value
  cache_test
  displayer_continuation
  collection_and_display_generation
  contents_valid
  movement_allowed
  child_pieces_and_nonchild_output
  old_region
  new_region
  state: matched | unchanged | moved | changed | inserted | deleted
}

Presentation records and redisplay pieces can be nested inside formatted-output records. They MUST remain distinct: presentation records answer “what object/type is here?”, while redisplay pieces answer “what output can be retained or changed?”.

Command and command table

CommandDefinition {
  name
  argument_specs_and_options
  body
  documentation
  menu_and_accelerator_metadata
  declared_visible_values
}

CommandTable {
  name
  parent_tables
  command_definitions
  accelerators
  menu_levels_and_items
  presentation_handlers
  mutation_epoch
}

A command object is a command name plus already accepted semantic arguments. It is independent of whether those arguments came from typing, completion, menus, or pointer gestures. Positional or conditional arguments not read yet MUST remain distinguishable from arguments explicitly supplied as NIL.

Surface syntax

The selected substrate accepts three presentation-type shapes:

1. an atomic type name;
2. (name . data-arguments); and
3. a full form containing name and data arguments followed by presentation arguments.

The compatibility frontend MUST decode all three without confusing presentation arguments with semantic data arguments. A descriptor can require data arguments, forbid atomic use, permit a Common Lisp type bridge, or mark itself presentation-only. Cache keys for appearance/parsing operations include presentation arguments; pure membership keys MAY omit arguments the descriptor proves irrelevant.

Definition and canonicalization

A type definition MUST declare separate data and presentation argument lists and MAY declare a supertype/expansion. Type specifiers are canonicalized by:

1. resolving the name to a current descriptor;
2. parsing supplied arguments and applying declared defaults;
3. preserving data and presentation arguments separately;
4. expanding aliases only as needed for the requested method or relationship;
5. detecting expansion cycles; and
6. retaining the original or reconstructible surface specifier for prompts and diagnostics.

Redefinition MUST increment an epoch and invalidate descriptor, method, subtype, and handler caches that could depend on the prior definition.

Canonical cache keys MUST be collision-safe. Genera bounds and compresses large type keys as an optimization. The INFERRED clean-room safeguard is that another implementation may retain full immutable keys, and a compact-key collision MUST never produce a false membership, method, subtype, or handler result. Descriptors with mutable or opaque arguments MAY opt out of caching.

Membership and subtyping

The relation presentation-subtypep(A,B) answers whether every semantic value of specifier A is acceptable where B is requested. Internally it has four possible results: true, false, unknown, or a conditional predicate which decides the relation for concrete arguments. A public two-valued wrapper MAY collapse unresolved results, but handler resolution MUST retain conditional information. It MUST account for:

• declared presentation-type inheritance/expansion;
• argument-dependent subtype rules;
• compound types such as conjunction, disjunction, membership, or predicate-refined types;
• an equivalent Lisp/host type only where the descriptor explicitly supplies one; and
• an unknown result when the relationship cannot be proved statically.

Presentation subtyping MUST NOT be replaced by raw host TYPEP alone. Two presentations of the same underlying integer can have distinct UI meanings, and a semantic subtype can be independent of object representation.

subtype(A, B, seen):
  normalize A and B
  if (A,B) is already in seen: return unknown
  remember (A,B)
  handle equality, top, bottom, and no-type sentinels
  ask A's descriptor-specific subtype method; retain a conditional result
  recursively try A's declared, generated, and equivalent supertypes
  try Flavor/CLOS precedence, structure ancestry, and declared host-type bridges
  return true on proof; otherwise the best conditional/unknown/false result

Traversal MUST detect cycles. Parameterized aliases or host-type expansions must terminate with an unresolved/false result or a structured error rather than recurse forever.

Method dispatch

Type-method lookup proceeds from the exact type descriptor through declared expansions/supertypes until a method for the requested role is found. Argument values must be available to methods whose behavior depends on them. The result MAY be cached against the canonical specifier, method role, and relevant epochs.

At minimum, a DW-G85/D0 implementation MUST provide method roles for:

Standard type-library boundary

The inspected selected modules contain 133 unqualified presentation-type definition forms: 44 core, 19 numeric, 15 sequence, 48 general, and 7 character-style. The general module also contains two explicitly SCL:-qualified definition calls, for 135 macro-family calls in a literal scan. Repeated MEMBER definitions, conditional forms, and package variants mean neither number is a count of unique live names. A reconstruction MUST ship a type library covering these semantic families:

• Lisp values and symbols;
• numbers, ranges, radices, and numeric subtypes;
• sequences, members, subsets, and structured compound values;
• pathnames, files, directories, and hosts;
• time and dates;
• fonts and character styles;
• systems, functions, classes, Flavors, and CLOS objects;
• windows, activities, printers, network and namespace objects; and
• application-extensible presentation types.

The source-form inventory is:

• Core (44): EXPRESSION, GPRINT::EXPRESSION-LENGTH-ELLIPSIS, FORM, EVALUATED-FORM, OUT-OF-BAND-CHARACTER, CONS, LIST, NULL, NOT, PARSE-ERROR-WALL, OR, AND, SYMBOL, KEYWORD, PACKAGE, FUNCTION, COMPILED-FUNCTION, GENERIC-FUNCTION, CLOS-INTERNALS:FUNCALLABLE-INSTANCE, LEXICAL-CLOSURE, DYNAMIC-CLOSURE, COMPILED-FUNCTION-PC, COMPILER:COMPILED-FUNCTION-AND-PC, CHARACTER, STANDARD-CHAR, STRING-CHAR, SIMPLE-STRING, UNBOUND-LOGIC-VARIABLE, HASH-TABLE, DECLARE, SIMPLE-ARRAY, READTABLE, LOCATIVE, SIMPLE-BIT-VECTOR, ATOM, STREAM, COMMON, SATISFIES, DATA-TYPE, CLI::EQUIVALENT, INSTANCE, CLOS-INTERNALS:MEMBER-OF-CLASS, CLOS-INTERNALS::MEMBER-OF-CLASS-NAMED, and STRUCTURE.
• Numeric (19): NUMBER, INTEGER, MOD, BIT, UNSIGNED-BYTE, SIGNED-BYTE, BIGNUM, COMPLEX, FIXNUM, FLOAT, SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT, FUTURE-COMMON-LISP:REAL, RATIONAL, RATIO, SMALL-RATIO, and BIG-RATIO.
• Sequence (15 forms): STRING, SEQUENCE, VECTOR, ARRAY, BIT-VECTOR, SIMPLE-VECTOR, SEQUENCE-ENUMERATED, MEMBER-SEQUENCE, two MEMBER forms, SUBSET, ALIST-SUBSET, SEQUENCE-ELEMENT, ALIST-MEMBER, and SEQUENCE-SUBSET.
• General (48 unqualified plus two SCL: calls): BOOLEAN, INVERTED-BOOLEAN, T, NIL, PATHNAME, FS:DIRECTORY-PATHNAME, FS:WILDCARD-PATHNAME, FS:OPEN-FILE, MENU-CHOOSE, TOKEN-OR-TYPE, NULL-OR-TYPE, TYPE-OR-STRING, TIME:UNIVERSAL-TIME, TIME:TIME-INTERVAL, TIME:TIME-INTERVAL-60THS, TIME:TIMEZONE-SYMBOL, TIME:TIMEZONE-NUMBER, TIME:TIMEZONE, FONT, SYS:FONT-NAME, SCT:SYSTEM, SCT:SUBSYSTEM, SCT:SYSTEM-VERSION, SCT:SYSTEM-BRANCH, SYMBOL-NAME, NET:OBJECT, NETI:NAMESPACE-CLASS, NETI:NAMESPACE-OBJECT, NET:LOCAL-HOST, NETI:LOCAL-NETWORK, LOCAL-PRINTER, PRINTER, TV:SHEET, TV:WINDOW, DW:DYNAMIC-WINDOW, TV:MICROCODED-GRAPHICS-ALU, TV:ALU-FOR-SHEET, SI:RESOURCE-NAME, SI:INITIALIZATION-LIST-NAME, FS:PATHNAME-HOST, FLAVOR-NAME, CLOS:CLASS-NAME, GENERIC-FUNCTION-NAME, CLOS-INTERNALS:GENERIC-FUNCTION-NAME, FLAVOR:INSTANCE-VARIABLE-ACCESSOR, FUNCTION-SPEC, SI:LISP-SYNTAX, KEYWORD-VALUE-PAIRS, KEYWORD-VALUE-PAIR, and TV:WINDOW-FLAVOR. SCT:SYSTEM-BRANCH and FLAVOR:INSTANCE-VARIABLE-ACCESSOR are the two explicitly SCL:-qualified calls.
• Character style (7): CHARACTER-STYLE-FAMILY, CHARACTER-STYLE-FACE, CHARACTER-STYLE-SIZE, CHARACTER-STYLE, CHARACTER-STYLE-FOR-DEVICE, CHARACTER-STYLE-DEVICE-FONT, and CHARACTER-FACE-OR-STYLE.

Exact argument lists and conditional live-name population remain an ABI metadata and world-oracle appendix. This inventory is sufficient to prevent a reimplementation from silently omitting an entire semantic family; it is not a claim that all 135 forms produce simultaneous distinct loaded types.

Inventory evidence: G85-SRC at dynamic-windows/core-types.lisp.~34~:137-1957, dynamic-windows/number-types.lisp.~5~:148-781, dynamic-windows/sequence-types.lisp.~28~:55-1893, dynamic-windows/presentation-types.lisp.~722~:58-1775, and sys2/character-style-presentations.lisp.~64~:371-671. Their exact byte identities are recorded in Artifact identities.

Numeric range types MUST reject values outside the requested range after syntactic parsing. Sequence/member/subset types MUST honor their supplied comparison functions and return associated semantic values rather than equating display strings. The character-style types cover family, face, size, device mapping, a combined style, and face-or-style selection. G85-SRC establishes these families; which conditional definitions are live in the patched world remains a metadata/oracle task.

PRESENT

Conceptually:

present(object, type_specifier, stream, view=stream_default, options):
  canonical = canonicalize(type_specifier)
  assert object satisfies canonical, unless options explicitly suppress checking
  begin presentation record with object, canonical, view, and sensitivity policy
  dispatch canonical's presentation-printer for view
  collect all text/graphics output and nested records
  compute or obtain highlight region
  attach record to current output history/record parent
  return object and/or printer-defined values according to compatibility API

An implementation MAY combine record construction with a scene graph, but the semantic record MUST exist independently of screen pixels.

An object/type mismatch MUST signal a structured, continuable presentation error. It cannot silently create a sensitive record that claims the wrong semantic type.

WITH-OUTPUT-AS-PRESENTATION

The scoped output form records arbitrary application drawing as one presentation. It MUST:

• retain the supplied object and full type specifier;
• collect the region of all enclosed output or accept an explicit region;
• preserve nested presentations;
• unwind cleanly after abort or error;
• avoid leaving a hit-testable record for output that never committed; and
• honor sensitivity and shared-box options.

Record ordering and hit testing

Records are ordered consistently with output and nesting. Hit testing at a pointer location MUST:

1. transform device coordinates into stream/history coordinates;
2. exclude records outside the visible viewport or clipped region;
3. descend from visually and semantically innermost eligible records outward;
4. respect a parent's policy for sensitive inferiors;
5. test the active context and applicable handlers; and
6. return the candidate sequence needed for priority/gesture resolution.

A bounding box MAY overapproximate drawn pixels. Selection follows the recorded region, not alpha-testing the framebuffer, unless a type supplies a more precise region test.

Output history

A Dynamic Window retains output records beyond the current viewport until explicitly cleared, superseded, or reclaimed by a documented policy. Scrolling changes the viewport over this history; it does not turn pixels into semantic objects. Clearing history MUST invalidate presentation hit testing and redisplay associations for the removed records.

Applications MUST clear or replace stale presentations when their objects cease to be valid. As an INFERRED implementation technique, a new implementation SHOULD use weak references or explicit lifecycle hooks where safe. The observable requirement is that a visible stale record MUST NOT invoke an operation on an unrelated replacement object.

Output history is mutable, not append-only. It MUST support replacing a presentation's semantic value/type, moving it with inferiors, erasing/deleting it, region redisplay, scroll shifts, clearing/compaction, and replay after exposure. The following atomicity rule is INFERRED: pixel changes and the semantic/spatial index commit together, or an exception invalidates the region and forces repaint rather than leaving clickable stale pixels.

Required modes

ACCEPT requests an object of a presentation type and MUST permit these input paths when supported by the type and context:

• typed syntax parsed by the presentation parser;
• completion over a type-specific possibility set;
• selection from presentation history;
• acceptance of a currently displayed compatible presentation;
• translation of a displayed presentation into the requested type;
• compound recursive acceptance of component values; and
• default acceptance, editing, or replacement.

All successful paths return a semantic object satisfying the requested context after postprocessing. The caller must not need to distinguish whether it was typed or pointed unless it explicitly requests input-source metadata.

Input transaction

accept(type, stream, prompt, default, options):
  canonicalize type and preprocess default
  push InputContextEntry
  establish input-editor and completion/history state
  loop:
    wait for keyboard, pointer gesture, or handler-produced event
    if text activation:
      parse under canonical type
      on incomplete input: continue editing/completing
      on type error: report locally and retain editable input
    if pointer gesture:
      resolve applicable handler under complete context stack
      direct translation -> candidate object
      action -> perform action, then continue accepting
      command result -> return/queue according to command-reader context
    validate predicate and type membership
    postprocess and record history if enabled
    commit editor state and return value
  on abort/error: pop context and remove transient feedback without committing

Context push/pop and transient highlighting MUST use unwind-protected cleanup.

Defaults, history, and completion

• A default is typed semantic state, not preinserted display text. The type can preprocess it and choose how it appears.
• Editing a default and selecting a default are distinct actions when the type supports both.
• History is partitioned or selected by presentation type policy. Recalled objects must be checked against the current full specifier and predicate.
• Completion MUST distinguish incomplete, ambiguous, unique, and invalid input. It SHOULD present possible completions using the same semantic type/view mechanisms.
• Parser errors MUST identify the failing type/context and leave the editor recoverable.

Presentation blips and stream rescan

The input editor and parser are deliberately separate. The parser consumes the editor's saved buffer. When the user edits already scanned material, the editor nonlocally returns to the read boundary and the parser runs again over the corrected buffer without re-echoing it. Parser code can therefore execute more than once and SHOULD avoid irreversible side effects before acceptance commits.

The editor buffer can contain presentation blips as well as characters. On screen a blip is abbreviated; during rescan it is returned as the semantic pointer event or translated value. :activation, preemptable input, command characters, static blips, dynamic blip handlers, notifications, and stream input-wait callbacks can return control before ordinary text activation. Already buffered input MUST survive these events.

EDITING:
  wait for character, editor command, activation, EOF, notification, or blip
  self-insert/edit -> mutate buffer and efficient echo; remain EDITING
  presentation blip -> insert one atomic semantic element; remain EDITING
  activation -> return activation boundary to parser
  parser requests rescan -> reset scan point and enter RESCANNING
  full rubout -> return the configured empty-input outcome

RESCANNING:
  return saved characters/styles/blips without waiting or re-echoing
  at saved boundary -> resume EDITING or return activation according to state

The selected source limits insertion to one million characters. A replacement SHOULD enforce a documented resource bound and signal a correctable condition rather than truncate, wrap an index, or split a semantic blip.

Input-editor dispatch and complete base command map

This subsection is the complete selected System 452.22 initialization of the base Input Editor character map. It is normative at DW-G85/D0; it is not a claim that a site has not changed the mutable map. A site-specific profile MUST dump the effective map after all ADD-IE-COMMAND and DELETE-IE-COMMANDS calls and record each replacement. A per-call :EDITOR-COMMAND entry shadows a base entry with the same character.

Dispatch precedes the command map in this exact order:

input-editor event
├─ list event
│  ├─ recognized nonpresentation redisplay special -> ignore it
│  ├─ other nonpresentation list -> beep and discard it
│  ├─ once-only presentation blip -> return it immediately
│  ├─ window-wakeup presentation blip -> run its configured callback/refresh path
│  ├─ input-editor presentation blip -> insert its history payload
│  ├─ other presentation blip -> insert one atomic semantic element
│  └─ presentation blip with activate option -> activate after the applicable path above
├─ NIL event (a discarded blip) -> perform no dispatch action
├─ rescan predicate accepts while reader/editor state differs -> save event and rescan
├─ configured do-not-echo character or EOF -> activate without normal insertion
├─ configured blip-character predicate -> return a blip with current numeric argument
├─ configured activation predicate -> return an activation blip
├─ configured command predicate -> return a command blip and rescan
├─ configured unmodified pass-through character -> insert without style conversion
├─ per-call :EDITOR-COMMAND map -> invoke its handler
├─ mutable base command map below -> invoke its handler
├─ Abort, M-Abort, Suspend, or M-Suspend -> standard keyboard interceptor
├─ any still-unhandled modified decimal digit -> extend numeric argument
├─ any still-unhandled modified minus -> set negative-sign argument state
├─ C-U -> start at four or multiply the current argument by four
├─ other nongraphic or format character -> beep, discard it, and clear numeric state
└─ graphic, Return, Tab, Backspace, or diacritic -> self-insert

The activation, command, rescan, and blip predicates are dynamic context options. They therefore override apparent base meanings. For example, a completion reader can consume Tab, Return, End, Help, C-?, or C-/ before the base map. Conversely, End is not a base end-of-buffer alias: without a context that activates on End, it reaches the nongraphic/unbound branch.

The base multi-stage and repeat grammar is therefore:

numeric argument
├─ modified digit -> decimal digit state
├─ modified minus -> sign state
├─ repeated modified digits -> signed decimal accumulation
├─ C-U -> 4, then 16, then 64, ...
└─ next editing command -> consume or ignore as stated above; reset argument state

C-Q
├─ unmodified character -> insert it literally without returning control to parser
├─ modified character -> editor barf/beep path; insert nothing
└─ noncharacter event -> keep reading for a character

C-M-S or C-M-R
└─ nested character ACCEPT -> use that semantic character as the viewport register

"Modified" in the Input Editor numeric branch means any nonzero character-bit state that has not already matched a dynamic option or command; it is broader than only Control and Meta. A normal command, self-insert, or random-control error resets the argument to one. Commands that do not consult it still consume and reset it. The balanced-expression commands are one such intentional example.

Consecutive compatible kills coalesce; a nonkill command breaks coalescing. Yank rotation is valid only after a compatible yank. Ordinary input history is selected by stream/type policy while the kill ring is shared. Semantic blips remain indivisible for character operations and may count as one Lisp expression for structural motion. The source also defines, but gives no base key to, display-internal-state, four matching-history display commands, vertical-scroll-beginning, vertical-scroll-end, and clear-history. They are extension points, not hidden bindings.

The complete source map and dispatch order above are no longer an oracle gap. Runtime behavior over styles, blips, history edges, failed viewport registers, and site mutations remains TODO-RUNTIME; those probes test the stated contract rather than license an omitted chord.

Completion state machine

Completion MUST retain at least five result states: no match, ambiguous prefix, left-substring match, unique extension, and exact/complete match. Sources may be sequences, arrays, alists, symbol sets, or indexed trees. They must honor configured case folding, delimiter conversion, display names, semantic values, and equality tests.

Ambiguity provides nondestructive feedback. Replacing text MUST preserve quoting and put point after the inserted material. Closed enumerated types cannot be bypassed by C-Return. An alist-backed completion returns the associated object, not the display name. Ellipsis choices expand only in the matching completion context. This is the complete selected completion-gesture inventory; maximal-completion and left-substring edge results still require TODO-RUNTIME oracle comparison, not an invented extra chord.

Evidence: G85-SRC at io/input-editor.lisp.~332~:120-2309, io/readers.lisp.~251~:62-71, and dynamic-windows/completion.lisp.~206~:743-1923; G8-MAN independently describes activation, rescan, preemption, parser/editor separation, and input-editor options. Only representative correction and pointer-blip paths are currently G85-RUN.

Compound types

A compound presentation parser may call ACCEPT recursively. The outer parser MUST maintain a procedural inverse relationship with its printer at the semantic level: values printed in an accepted view should be reconstructible or selectable even when the textual syntax is not a literal Lisp form. Nested input contexts MUST let the pointer satisfy the innermost component while retaining the outer continuation.

Logical gestures

Handlers name logical gestures such as Select, Describe, Menu, or application-defined gestures. A gesture mapping converts raw button/modifier/key events into those names. Applications MUST NOT need to hard-code host button numbers. The mapping is part of the user/environment profile and can vary without redefining every translator.

The selected initialization first creates one unique primary gesture for every one of 32 Shift/Control/Meta/Super/Hyper bit states on each of three buttons: 96 raw characters in all. The table lists the additional aliases installed on named states. Every unlisted state, including Hyper-only and other multi-modifier combinations, retains only its unique primary gesture. A physical chord can therefore name more than one logical gesture so different handlers can bind the same chord in different semantic contexts.

Primary names preserve the historical formatter: numeric bit state 3 is specially spelled CONTROL-META, while other combinations use Hyper, Super, Meta, Control, then Shift order. For example state 19 has primary META-CONTROL-SHIFT-{LEFT|MIDDLE|RIGHT} names even though source character syntax uses the c-m-sh order for its Monitor/Unmonitor aliases.

The complete primary-state inventory is below. Each row expands to the three raw characters <prefix>LEFT, <prefix>MIDDLE, and <prefix>RIGHT; state 0 uses no prefix. This is an exhaustive 96-cell map, not a representative subset.

The physical encoder chooses the highest newly-down button bit, so Left+Middle is Middle and every simultaneous newly-down set containing Right is Right. It waits a configurable interval for release/repress of that same button, suppresses double-click construction when keyboard input is pending, ORs Shift into a recognized second click, and stops after the second click. Consequently there is no triple-click encoding; a NIL interval disables double-click construction entirely; and Shift+single and an unmodified double click are indistinguishable. An exact CHAR-MOUSE-EQUAL Shift-Right/Right-double match is consumed by Essential Mouse before Dynamic Windows: it opens System Menu when console-enabled and otherwise beeps, with no Dynamic Windows fallback. Direct logical-character tests MUST therefore be separated from physical transition tests.

Gesture metadata also says whether raw text is required, whether a presentation description should be requested, and whether documentation appears without a normal semantic match. Remapping a chord MUST invalidate handler and pointer-documentation caches.

The fixed selected-source contract comprises all 96 primary cells, initialization aliases/order, highest-newly-down-button and Shift-OR double rules, lookup/context/dead semantics, and built-in handler definitions. Mutable/profile inputs comprise gesture remapping, loaded handlers and command tables, active contexts and selected window, tester/capability/object state, host keyboard-to-internal modifier mapping, double-click timeout including NIL-off, and local-versus-remote debounce. A conformance report MUST record these inputs rather than presenting initialization as an immutable global keymap.

Applicability

A handler is potentially applicable when:

• the presented type is equal to or a subtype of the handler's source type;
• the handler's result target can satisfy an active input context, or its command table applies in the current command environment;
• the event maps to the handler's logical gesture;
• its tester succeeds for the object, record, context, and environment; and
• its menu/blank-area/nesting policy permits the current invocation.

For selected displayed type D, handler source type S, requested context type C, and declared handler result type R, source applicability requires D <: S and target applicability requires R <: C. A translation that returns an object failing the context predicate MUST be rejected after translation. Here R is a variable, not the historical universal presentation type named T.

Resolution algorithm

Routing to this algorithm is selected-window-sensitive. If the selected window implements :PRESENTATION-INPUT-BLIP-HANDLER, the clicked window supplies the hit presentation and coordinates but the event is enqueued through the console system-I/O buffer, so the selected window's active contexts and command table govern resolution. Otherwise input is forced to the clicked window. On blank area, the generic unmodified-Left Select This Window handler applies only when clicked and selected window aliases differ.

The following is normative at the semantic level:

resolve(pointer, raw_event, context_stack, command_table):
  actual_char = raw_event's exact mouse character
  chord_chars = LEFT, MIDDLE, and RIGHT characters sharing actual_char's modifier bits

  (presentation, highlighted_context) =
    innermost_sensitive_presentation(pointer, chord_chars,
                                     obey_suppress_highlighting = true)
  # This walks the hit presentation's enclosing-presentation chain under the
  # shared-sensitive-box/context rules; it is not a Cartesian scan of all hits.
  if presentation exists:
    try actual_char on that presentation in highlighted_context
    if a handler is found: invoke it and normalize its result as below

    seen_presentation_types = EQ identity set
    for context in context_stack from innermost to outermost:
      if context.presentation_type is EQ to a previously seen type: continue
      remember context.presentation_type
      try actual_char on the same presentation in context
      if a handler is found: invoke it and normalize its result as below

  (actual_presentation, ignored_context) =
    innermost_sensitive_presentation(pointer, [actual_char],
                                     obey_suppress_highlighting = false)
  if actual_presentation exists:
    seen_presentation_types = EQ identity set
    for context in context_stack from innermost to outermost:
      if context.presentation_type is EQ to a previously seen type: continue
      remember context.presentation_type
      try actual_char on actual_presentation in context
      if a handler is found: invoke it and normalize its result as below

  consider applicable blank-area or command-menu handlers
  if no matching handler: signal dead-blip; beep only if unhandled; return (dead-blip)
  if a found handler returns NIL without an explicit non-NIL type, or explicit (dead-blip):
    return (dead-blip) directly without the no-match signal/beep path

Each try maps the actual character to its ordered primary gesture and aliases, then indexes handlers by presentation type and gesture. It expands all-gesture handlers for direct/menu mode, requires displayed type below handler source type and handler target below requested context type, runs object and context/result testers, rejects explicit no-applicability, applies menu-presence and exclusion rules, and sorts the surviving candidates by the selected priority/context/direct-menu rules. Translation is speculative only where result-dependent testing requires it, and rejection reasons remain available to diagnostics.

The subtype directions are normative: the displayed type is below the handler source, and the handler target is below the requested context. Reversing either test admits results the acceptor cannot consume or lets overly specific handlers claim general objects. Nesting preference comes from the explicit two-pass presentation selection and same-presentation context retry above. The selected source's final same-priority name comparator contains an apparent comparison typo, so this profile does not turn intended package/name order into a false compatibility claim: a conforming preserved-world profile MUST dump the effective order wherever such a tie exists. An implementation MUST retain diagnostic reasons for candidate rejection so behavior can be inspected.

Exact Right on a presentation opens an Operation menu whose unstyled entries precede styled submenu entries; each group sorts case-insensitively by label, duplicates are removed, and the most recent choice is remembered separately per menu type. The styled candidates include Marking and Yanking Menu whenever an active si:input-editor context makes that named menu nonempty. The generic blank-area menu always offers Window Operation Menu, adds System Menu when console-enabled, can add Select This Window when the alias tester succeeds, and adds Marking and Yanking Menu when an active si:input-editor context makes that menu nonempty. A nonempty menu dismissed without a choice returns silent semantic (dead-blip) through the found-handler path. An empty applicable menu beeps explicitly before returning the same semantic result. Presentation Debugging is not a blank-area member; loading Presentation Inspector can make its Super-Right named menu nonempty for ordinary nonanonymous presentations when the debugging tester succeeds.

Configured built-in handler catalog

This catalog closes the selected-source three-module identity/gesture boundary. It contains 54 active definitions and 66 source-emitted handler records: 42 definitions and 50 records in BASIC-HANDLERS, four definitions and seven records in HANDLER-DEBUG, and eight definitions and nine records in Presentation Inspector. The apparent SI:COM-COPY-FILE-TO-LIB form is inside a block comment and is not a definition. The ordinary-Zmacs selected-source inheritance boundary contains a bounded 47-definition/59-record subset: one Presentation Inspector definition contributes two Presentation Debugging records, while its seven presentation-to-command translators require a compatible nested Command Processor context. Whether every record was resident or later redefined in the preserved world remains a runtime question.

typed+blank means one declared typed record plus a generated NO-TYPE blank-area record. An omitted priority is zero. An omitted translator gesture is :SELECT; a NIL gesture is menu-only. Op, Blank, MY, and PD mean the ordinary Operation, blank-area Operation, Marking and Yanking, and Presentation Debugging menu categories. Effects are original technical descriptions, not copied source documentation.

The remaining seven Presentation Inspector records are part of the complete selected-source denominator but not ordinary Zmacs leaves. All are composable, have priority zero, and appear in the ordinary Op menu when their target Command Processor context admits the constructed command.

Handler Debug also defines three named commands in command table Presentation: Show Mouse Handlers, Show Presentation Type, and Show Handlers for Types. Presentation Inspector adds Show Presentation Handlers From Type to that table and has ten local commands/menu labels: Show Handlers This Presentation, Show Handlers All Presentations, Describe Handler, Show Handler Applicability, Show Handler Context Applicability, Show Input Context, Show Presentation Hierarchy, Set Presentation, Help, and Exit. These are command-table entries, not raw-key bindings inherited by Zmacs. The seven rows above are the typed pointer routes into those commands; INVOKE-PRESENTATION-INSPECTOR is the only Presentation Inspector definition on ordinary Zmacs's inherited PD menu edge.

The ordinary Zmacs reader requests (OR PRESENTATION-COMMAND SI:INPUT-EDITOR). Input Editor handlers are therefore inherited candidates. FORM, CP:COMMAND, IN-BAND-MENU, and presentation-type-name translators need a corresponding nested input context; pathname command translators are not ordinary Zmacs leaves merely because they are globally registered. ZWEI BP expands to Dynamic Windows RAW-TEXT, so the raw-text rows do apply to Zmacs.

Application and inherited precedence is exact:

1. Zmacs COMPATIBLE-COMTAB-LOOKUP has all-gesture T and is searched before named gestures. If its tester finds an effective fixed comtab leaf, it wins and routes the exact raw mouse character through ZWEI; otherwise inherited named candidates continue.
2. Search walks requested-context subtypes and displayed-type supertypes. Non-T displayed handlers precede handlers declared on T. Score adds explicit priority, two for exact requested-context type name, and four for exact displayed-type name. The source's final equal-score name comparator accidentally reads handler two twice, so equal-score order remains a live oracle.
3. No definition above excludes other gesture buckets. Menu-only handlers are considered only through an applicable menu-defining action of the same category. Direct handlers remain menu candidates unless menu is NIL.
4. Menu assembly reruns type/test/context gates, removes same-label or same-value duplicates in the same/context-independent context, places unstyled before styled entries, sorts each group case-insensitively, and remembers last choice per category. An empty submenu makes its defining action inapplicable. Direct invocation of an empty menu beeps/dead-blips; dismissing a nonempty menu dead-blips silently.
5. Actions are noncomposing. Ordinary side-effect completion reaches the action macro's NIL fallback and normalizes to dead-blip; menu actions can return their nested menu result before that fallback. The explicit noncomposing translators are Yank Word, Yank Marked Text, Yank From Kill Ring, Clear Marked Text, and Edit Presentation Handler. Other translator results must satisfy the target context predicate.
6. :BLANK-AREA T on displayed T adds a no-type record; it does not duplicate a no-type definition. A displayed no-type record whose object type is not no-type cannot use blank handlers.
7. With no surviving candidate, dispatch signals dead-blip, beeps only when unhandled, and returns dead-blip. A found handler returning NIL with no non-NIL type returns dead-blip without the no-match signal/beep. There is no generic modifier-stripping fallback.

Handler results

Documentation and highlighting MUST be computed from the same effective candidates used for dispatch. The bottom mouse line must not promise an operation whose tester would reject the eventual click.

Caching and invalidation

Handler lookup MAY be cached by canonical source type, target context, gesture, command table, and relevant epochs. Cache entries MUST be invalidated when a type, handler, gesture mapping, command table, or predicate-dependent registration changes. Object-specific tester results SHOULD NOT be cached beyond a stability scope unless the tester declares a valid cache key.

The 1989 paper reports performance and global-cache difficulties. A new implementation is not required to reproduce those inefficiencies; it IS required to reproduce dispatch results and cache invalidation behavior observable by applications.

Evidence: G85-SRC at define-handler.lisp.~12~:65-587, mouse-handler-lookup.lisp.~33~:1452-2220, dynamic-input.lisp.~498~:243-367,1160-1239, dynamic-window-mixins.lisp.~204~:708-743, basic-handlers.lisp.~30~:127-1381, handler-debug.lisp.~33~:96-307, presentation-inspector.lisp.~4053~:588-1079, clcp/iofns.lisp.~273~:2562-2584, io/format.lisp.~369~:1006-1036, and window/mouse.lisp.~472~:631-700,1153-1163,1862-1867; UIST89 independently corroborates source and target subtype direction, nested contexts/presentations, testers, priorities, menus, and documentation. The inspected live handler report is G85-RUN; equal-priority and exclusion conflicts remain TODO-RUNTIME.

Command definitions

A command definition declares semantic arguments using presentation types, optional defaults and prompts, a body, and menu/accelerator/documentation metadata. The command reader MUST build a command object by accepting each argument in order. Pointer and typed input can be mixed within one command.

Only keyword-style option groups are admitted by the selected command-definition grammar. Positional arguments not read yet are represented as optional/unread slots; that state is distinct from an explicitly supplied NIL. A later argument can become visible or required conditionally on earlier semantic values. Parser and unparser operate on the same command object. Unless a command explicitly declares visible values, incidental multiple values from its body are hidden from listener history.

Command tables

Command tables MAY inherit from multiple parent tables. Lookup MUST be deterministic and detect cycles. The selected rule is depth-first traversal in declared parent order, with the first found binding winning. A table can contribute:

• command definitions or references;
• typed command-name completion;
• keyboard accelerators, including whether single-character reading is enabled;
• menu levels and item order;
• presentation translators and command translators; and
• generated Help/documentation.

Mutating a table MUST invalidate effective-command, accelerator, menu, and handler caches for its descendants.

The default name map is case-insensitive and keyboard accelerators can be enabled or disabled per table. The global registry must preserve explicit if-exists behavior and stable table identity when callers retain the object.

Prefixes, accelerators, and command-or-form reading

Accelerators are direct mappings or prefix-tree states. A prefix is not itself a completed command unless explicitly bound as one. Inherited accelerators follow the same table-order contract as command names. Numeric arguments can precede an accelerator, are visible in its prompt, and are delivered through the accelerator's argument contract.

READ-COMMAND:
  establish command input context, active table, program wakeups, and Help
  read keyboard gesture, presentation blip, or edited command text
  if gesture extends an accelerator prefix:
    retain prefix and numeric state; show legal continuations; read again
  if gesture completes an accelerator:
    construct its command object and arguments
  if text begins a full command:
    complete/parse command name, then ACCEPT each typed argument
  if a presentation translator yields a command:
    validate it through the same command-object path
  if form evaluation is enabled and the selected syntax denotes a form:
    return the form to the framework evaluator
  on correction:
    retain editable input and retry without executing a partial command

The selected command-or-form reader treats alphabetic input as command-preferring and recognizes colon/comma-prefixed paths for full-command/form interpretation. A failed command parse MUST NOT fall through to evaluation unless the documented reader state allows it. Exact prefix-key presentation and every colon/comma corner are TODO-RUNTIME; implementations MUST first match the source state machine rather than guess from modern shell conventions.

Command loop

program_command_loop(frame):
  while frame remains active:
    choose terminal_io and selected interaction pane
    establish frame command table and input context
    read command from typed name, accelerator, menu, or presentation translator
    execute command with semantic arguments
    handle abort locally and serious conditions through the configured debugger path
    run post-command hooks
    request full or incremental pane redisplay according to framework policy

The visible command menu and typed interactor MUST be two surfaces over one command model. A menu click must not call a separate callback that bypasses argument typing, command documentation, or command-loop hooks.

Noun-verb and verb-noun use

The implementation MUST support both:

• command first, then typed or pointed operands; and
• object first, then a presentation-to-command gesture or menu choice.

The resulting command object and application effect SHOULD be equivalent when the same command and semantic arguments are chosen.

Evidence: G85-SRC, cp/comtab.lisp.~103~:55-423, cp/command-processor.lisp.~318~:532-1082,1396-1792,2328-2596, and cp/read-accelerated-command.lisp.~142~:55-214,368-831; G8-MAN corroborates typed arguments, hierarchical tables, completion, Help, and accelerators. Resident program loops are G85-RUN; synthetic inheritance/prefix conflicts are TODO-RUNTIME.

Box model

Each formatted construct produces a box with minimum, desired, and resulting extent, children, and alignment/break policy. Required construct families include:

• tables, rows, and cells;
• item lists arranged by rows or columns;
• filling text, indentation, textual lists, and conditional line breaks;
• multiple columns with premeasurement;
• replayable and resortable output;
• abbreviation by width, height, ellipsis, or newline substitute;
• centering, underlining, and temporary character styles;
• explicit-coordinate output and embedded subwindows;
• surrounding rectangular or curved borders;
• graphs/trees with node and edge layout; and
• output-size measurement and hardcopy coordinate conversion.

Layout proceeds in at least two logical phases: measure/collect constraints, then assign positions and render/replay. A new implementation MAY merge phases when output metrics are known, but it MUST preserve nested alignment and conditional-break results.

Tables and item lists

A table MUST align cell boundaries across rows, honor intercolumn/interrow spacing, and support alignment within cells. An item list MUST choose or obey row/column geometry, preserve item order, and retain individual output/presentation records. A cell's semantic records move with the cell and remain hit-testable at assigned coordinates.

Filling derives its default column from usable viewport/inside width; when no geometry exists the selected implementation uses an approximately 95-character fallback. Spacing accepts numeric distance, measured strings, character/pixel units, or measured continuation output. Those forms MUST normalize to one coordinate unit before layout. Simulation must reproduce styles, presentations, indentation, filling, graphics cells, and coordinates without accidentally attaching measured presentations to the live output history.

Deferred lexical state

Historical formatted-output and redisplay forms can capture lexical state for replay. A reimplementation MUST define capture semantics explicitly. Values needed for a stable replay SHOULD be snapshotted at record creation; values declared shared or dynamic MUST be reread when replayed. The API MUST provide an escape for intentionally mutable shared variables so cached output does not silently freeze application state.

Evidence: G85-SRC, formatted-output.lisp.~397~:76-2681; G8-MAN documents the public formatting families and replay model. Runtime clients demonstrate visible formatted output, but width rounding, continuation execution counts, every border, hardcopy inversion, and the geometry-free fill fallback remain TODO-RUNTIME.

Redisplay contract

An application describes a new output-record tree. Stable unique IDs relate new redisplay pieces to old pieces. A cache value and comparison test say whether content remains semantically unchanged. Geometry can change even when content does not.

Reconciliation algorithm

COLLECT:
  run the application displayer against a simulated/recording stream
  for each updating piece in encounter order:
    match an old sibling by scoped unique ID and compatible piece class
    if no ID was supplied, fall back to the next compatible old position
    compare cache values with the piece's declared test
    retain old recorded output only when cache matches and contents remain valid
    otherwise collect new output and inferiors

LAYOUT:
  compute natural sizes, table constraints, row/column/cell geometry, and final boxes

PLAN-MOVES:
  promote reusable unchanged pieces
  identify safe pixel copies for pieces whose boxes moved
  order overlapping copies so no source pixels are destroyed before use
  calculate stale/exposed regions and presentation relocations

DISPLAY:
  encounter exactly the same piece identities, classes, and order as COLLECT
  copy safe unchanged pixels; replay any unchanged piece that cannot be copied
  erase stale regions in overlap-safe order
  execute/replay changed pieces and attach their presentations
  update boxes, cursor, parentage, output history, and spatial indexes

COMMIT:
  atomically install the new piece tree and generation; discard stale presentations

ON ERROR OR COLLECTION/DISPLAY MISMATCH:
  invalidate the affected subtree and force a coherent full redraw

Unique IDs need only be unique within the declared redisplay scope. Duplicate IDs in one scope MUST be diagnosed or handled deterministically; silently matching one at random is nonconforming.

The collection/display identity rule is fundamental. Application display code can be executed twice, and a branch that emits a different piece sequence in the display pass is not allowed to attach old pixels or presentations to a different semantic piece. Independently redisplayable formatting whose geometry depends on surrounding flow MUST escalate to the nearest safe ancestor rather than update in isolation.

Correctness rules

• An unchanged cache value is an application assertion. The framework MAY offer a debugging mode that recomputes and compares output.
• A changed child's old region must be erased even if the new child draws less area.
• Moving a record updates every nested presentation's transformed region.
• Reordering overlapping siblings must preserve final visual order even if each is individually unchanged.
• Scrolling and clipping can make a retained record newly visible or invisible; presentation eligibility follows current visibility.
• Clearing output history removes matching redisplay and presentation records.

Evidence: G85-SRC, redisplay.lisp.~185~:57-2590; G8-MAN corroborates unique IDs, cache values, independent output, and pane-level incremental redisplay. The exact collection/layout/promotion/copy/display machinery is source-established; pixel-copy ordering, execution counts, mismatch recovery, and duplicate-ID behavior remain TODO-RUNTIME oracle tests.

Required Genera-TV and stream subset

Dynamic Windows assumes that its host provides:

• hierarchical sheets/windows and parent/child coordinate transforms;
• inside and viewport geometry, clipping, exposure, refresh, damage, and scrolling;
• character output, cursor state, text styles, and line metrics;
• keyboard and pointer queues plus stream listen/wait/wakeup operations;
• frame/constraint pane creation and configuration;
• process ownership and an Abort/nonlocal-exit boundary;
• selection, mouse documentation, menus, activities, and System Menu/Select hooks;
• raster operations or a semantically equivalent rendering backend; and
• ordinary stream operations such as input, output, fresh-line, cursor movement, and capability introspection.

Dynamic Windows adds typed semantic output history; it does not replace those host contracts. A reimplementation SHOULD place them behind a narrow interactive-stream and window-backend protocol. The public MIT TV specification is useful lineage evidence, but only these requirements are normative for this DW-G85 profile.

Output modes and coordinate spaces

Drawing and recording are independent dimensions. Normal output draws and records; history-only output records without drawing; direct/clear-region output draws without recording. Text, formatted output, and graphics MUST preserve that distinction so measurement, replay, erasure, and live output do not accidentally create or omit semantic history.

At least five spaces must be distinguishable: application/logical graphics, stream-inside, viewport, parent/screen, and raster-local coordinates. Every recorded box declares or can convert from its space. Scroll and pane movement translate boxes; pointer hit testing transforms into the space in which the recorded operation was defined. Hardcopy may invert the vertical axis without changing the logical presentation geometry.

Viewport-aware ragged margins

For a Dynamic Window with the ragged-border margin component, each edge MUST remain a straight rule when no retained extent continues beyond that edge and MUST become the repeating ragged rule when its predicate is true:

left   = viewport.left > 0
top    = secondary_viewport_exists OR viewport.top > 0
right  = viewport.right < maximum_x_position
bottom = secondary_viewport_exists OR viewport.bottom < maximum_y_position

The four values are independent except for the secondary-viewport rule, which forces both top and bottom true. The component MUST allocate and draw top and bottom. Left and right MUST also be allocated and drawn by default, but an application MAY disable that pair with the selected profile's horizontal-too option. Disabling the pair does not change the continuation predicates themselves.

The horizontal and vertical ragged paths have a ten-device-pixel period. A strict visual implementation MUST preserve the selected source's right alignment for a partial horizontal period and bottom alignment for a partial vertical period. The configured thickness defaults to two pixels; allocation adds two pixels for the diagonal excursion. A false edge uses the same allocated margin and a straight filled rule rather than collapsing the margin.

After viewport movement, the component MUST compare all enabled edge predicates with its cached state. It MUST erase the old form and draw the new form only for edges whose predicate changed. This update is margin raster output, not retained Dynamic Window output; it MUST NOT add presentation or redisplay records. If the pane is unavailable for drawing during a failed scroll, the backend MUST leave it marked for a complete margin repaint rather than commit cached state that disagrees with the visible edge. The last sentence is INFERRED recovery policy; the source establishes the ordinary erase/draw order but not a portable host failure protocol.

Evidence: G85-SRC, dynamic-window-mixins.lisp.~204~:1260-1405,2808-2852, dynamic-window.lisp.~625~:3082-3089, and dynamic-window-flavors.lisp.~29~:157-171. The reviewed debugger-dynamic-choices.png is G85-RUN for one top-ragged, side-straight state. The ragged-border analysis records the broader caller inventory and exact screenshot boundary. Active side edges remain TODO-RUNTIME.

Process ownership, locks, and callbacks

The source establishes owning-process operations, asynchronous exposure/scroll work, registry protection, generations, and nonlocal callback exits. The following serialization policy is INFERRED: each output history has one serialization boundary, and an exposure/scroll process cannot mutate history concurrently with an application displayer without a transaction or owning-process handoff. Type, handler, gesture, and command registries MAY use locks plus generations or immutable snapshots. Input wakeups MUST not lose already buffered characters or blips.

The following callback-lock rule is also INFERRED: no implementation SHOULD invoke arbitrary application printers, parsers, testers, translators, redisplayers, or documentation functions while holding a global registry lock. Every callback can signal or exit nonlocally; unwind cleanup must release locks, pop contexts, remove feedback, and mark partially changed regions for repaint.

Activities and remote degradation

Activity selection and reuse are host-TV services consumed by frameworks. A framework definition registers an activity only when its policy requests it; creating an individual Dynamic Window frame does not repeat that registration. Activity compatibility must be checked before reusing a frame. Registration, resident definition, activity availability, and a live instance are four distinct states.

Plain, background, or remote streams can lack spatial history, pointer input, raster graphics, or local pane creation. PRESENT/ACCEPT, completion, commands, FQUERY, and Accepting Values MUST capability-test and degrade to textual behavior where their semantics permit it. They MUST NOT fabricate pointer sensitivity or assume every TV stream is a Dynamic Window. Serial Accepting Values and FQUERY preserve typed values, defaults, validation, and Abort even when layouts and mouse choices disappear.

Evidence: G85-SRC, dynamic-window.lisp.~625~:225-3844, accept-substrate.lisp.~19~:397-1339, accept-values.lisp.~244~:403-510, and window/activities.lisp.~35~:65-554; G8-MAN establishes the public TV/stream, activity, and remote facility boundaries. Ordinary live windows are G85-RUN; exact plain/background/remote fallbacks and cross-process exposure races are TODO-RUNTIME.

Declarative definition

DEFINE-PROGRAM-FRAMEWORK conceptually expands one declaration into:

• a program/frame class or flavor;
• declared program state and accessors;
• a command table and command-defining facility;
• pane definitions;
• one or more named frame configurations/constraints;
• terminal-I/O and selected interaction pane policy;
• activation, selection, deactivation, deexposure, kill, command-loop, and redisplay hooks;
• a top-level creation/selection function and process policy; and
• optional activity, System Menu, and Select-key registration.

The generated pieces MUST remain inspectable. Framework generation MUST reject duplicate pane/state names, unresolved panes in configurations, command-table cycles, and impossible default interaction panes before registering a partially functional program.

Program state

State variables belong to the program instance and can be used lexically by generated commands and redisplayers. Declared defaults become program-flavor slot defaults and are established when the program instance is made. Caller-supplied state-variable overrides are applied while the owning frame is being initialized, before ordinary program use. The selected framework does not define a separate generic "initialization hook" between pane construction and the top-level loop; an application that needs extra instance initialization supplies it through its flavor/class facilities. Redefinition MUST define how existing instances migrate or require recreation; it must not silently reinterpret old slot storage.

Lifecycle

DEFINE:
  parse and validate program, pane, configuration, and state declarations
  define/update the program flavor, frame-option constructor, and command table
  if selectable, define the activity and optional Select-key/System-Menu entries

INSTANTIATE:
  ask TV to make a program frame
  during frame pre-initialization, make the program instance and apply state overrides
  copy pane descriptions and selected/query/terminal/label role options into the frame
  let the TV frame/constraint lifecycle construct the initial panes and configuration
  after frame initialization, diagnose an unusable NIL selected pane

ACTIVATE/SELECT:
  let TV perform activation and selection
  invoke the after-activation and after-selection program hooks at those phases
  update the console's selected-program bookkeeping after selection

TOP-LEVEL/RUN:
  in the frame process, bind terminal, query, standard-input, and standard-output streams
  invoke the configured program top level
  under the default top level, perform initial redisplay in the command input context
  read accelerator, command, translated presentation, form, Help, or wakeup
  execute in program context; record visible values/history by policy
  handle Abort at a stable command boundary; repeat

RECONFIGURE:
  serialize against the owning frame process
  install/reuse panes according to configuration policy
  rebind role streams; resize/expose; redisplay affected panes

REUSE:
  search activity frames by program identity and the optional reuse predicate
  select a compatible existing frame instead of creating one when policy permits
  if caller-supplied state overrides are present, reset them, clear the frame, and reset its process

DEACTIVATE/DEEXPOSE/KILL:
  invoke the before-deactivation hook before TV deactivation
  invoke before- and after-deexposure hooks around TV deexposure and update console bookkeeping
  invoke the before-kill hook before TV destroys the frame
  retain the definition-time activity registration until the program definition changes

Activity registration is therefore a definition-time effect, not a CREATE-phase effect, and starting the default top level is not a second generic initialization hook. A framework can specify :selectable nil; that defines a reusable internal program without defining its activity or System Menu/Select-key entries. Registration, loaded definition, activity availability, and a live instance are distinct facts.

Panes

The selected source registers seven standard pane families and permits further dynamic registration:

Therefore pane type enumeration MUST be dynamic; a designer or introspector cannot hard-code this table as the permanently complete universe.

Display panes accept a string or a function redisplayer under mutually compatible options. Their incremental policy distinguishes full clear/redraw, updating-output, viewport-limited updating, and an application-owned redisplayer. Forced redisplay invalidates/clears existing records. A redisplayer error MUST offer a controlled skip/debug/retry path while leaving the frame structurally usable.

Configurations and constraints

Pane configurations form a tree of rows, columns, panes, and size constraints over the underlying TV frame. The solver must allocate exact integer geometry and preserve the TV frame invariants. Switching configurations deexposes absent panes, exposes present panes, updates selected/terminal-I/O panes if needed, and invalidates formatted and presentation regions affected by movement.

Pane parsing validates unique names, infers conventional query/selected/terminal/label roles, and can turn output-measured sizing into a request to the TV constraint system. If no explicit configuration is supplied, every declared pane appears in a default vertical column. A configuration switch MUST occur in a safe owning-process context, rebind all role streams, and repaint newly exposed or resized panes.

Bounded runtime evidence: the reviewed Frame-Up capture shows one live split-pane configuration after the recorded synthetic layout interaction. It supports the pane/configuration claim, not every constraint rule or framework lifecycle branch. Portable provenance and the image-specific rightsholder/fair-use analysis are in the Genera screenshot asset catalog; the image is scholarly evidence, not a decorative gallery item or a runtime dump.

An activity advertises a name, selection key/System Menu entry, compatibility test, and creation/reuse operation. Selection SHOULD find and raise an existing compatible frame before creating another when reuse is enabled; it must not rerun destructive initialization merely to expose the old frame.

Evidence: G85-SRC, program-framework-panes.lisp.~32~:58-459, define-program-framework.lisp.~332~:55-340,1106-1233,1343-1426,1726-1789, and window/activities.lisp.~35~:65-554; G8-MAN documents frameworks, the original six overview pane families, configuration, and redisplay options. The Frame-Up split is G85-RUN; default-column creation, every pane type, role inference, measured sizing, reuse, and failure restarts remain TODO-RUNTIME.

Query model

AcceptingValuesQuery {
  id
  presentation_type
  prompt
  value
  default_and_default_state
  changed_by_user
  presentation_type_actually_read
  redisplay_piece
  start_position
  required_or_confirmation_policy
  dependency_or_cache_value
  displayed_value_presentation
  chooser_or_samples
  continuation
}

ACCEPTING-VALUES repeatedly runs a display body inside redisplay. Query IDs MUST be stable across iterations so values and presentations match. Editing a query updates its semantic value, validates it, records history when enabled, and redisplays the query plus any dependent output whose cache changed.

When an explicit query identifier is absent, the selected source derives one from a string prompt, or otherwise from the presentation type. The query table compares keys with EQUAL. Repeated same-prompt/type queries therefore MUST supply distinct explicit identifiers. An unchanged query can adopt a changed application default according to the selected default policy; a user-changed query retains its value unless the application explicitly resets it.

SIZE/DISCOVER:
  run body; establish query identities and natural output size
DISPLAY:
  rerun body through updating output; match each query by identity
READ:
  accept pointer choice, field edit, navigation, Refresh, End, Abort, or command
EDIT FIELD:
  edit inline, in a limited area, at form end, or in a separate window
  parse through ACCEPT; on failure retain old semantic value and correction text
RESYNCHRONIZE:
  rerun body; add/remove conditional queries; preserve matching changed values
RETURN:
  rerun in return mode so each query yields its final semantic value

The facility dispatches by stream capability. Plain/remote streams use serial prompts; a Dynamic Window can edit inline; a non-Dynamic TV stream can use a separate screen/window; an Accept Values pane participates in its owning framework.

Interaction contract

The standalone DW-G85/D4 form is a keyboard-accelerated program whose local command table inherits exactly standard scrolling and standard arguments. It does not inherit Colon Full Command, Unshifted Arguments, or the Input Editor map at its idle command boundary. The selected source initializes this complete direct map:

Space, C-E, and C-D signal an accelerator error when neither a query nor choice is highlighted. Query/choice motion never wraps. Positive motion from a NIL cursor finds the first query or choice; negative motion from NIL beeps. Motion beyond either end beeps and preserves the preceding cursor. Negative counts reverse direction. A zero query count reselects the current query when non-NIL and beeps when there is no current query. For a zero choice count the selected source takes a single-value branch and supplies NIL as the presentation to the highlighting setter; a strict implementation MUST retain that call path rather than silently invent wrap or no-op behavior. The exact condition/result of that edge in the loaded world is TODO-RUNTIME.

The inherited standard scrolling table contributes this exact map. These are accelerators at the idle form boundary, not aliases from the Input Editor table:

The inherited argument grammar is a multi-stage binding tree, not a free-standing command:

Accepting Values idle
├─ C-U -> argument 4
│  └─ C-U repeated -> multiply by four each time
├─ Control-, Meta-, or Control-Meta-minus -> negative-sign state
├─ Control-, Meta-, or Control-Meta-digit -> decimal digit state
│  └─ more modified digits -> signed decimal accumulation
├─ selected modified infinity-argument character -> signed infinity state
└─ next accelerator
   ├─ C-N, C-P, C-F, or C-B -> deliver signed count
   ├─ forward/backward vertical, horizontal, or typeout scroll -> deliver count/mode
   ├─ another argument character -> continue argument state
   └─ every argument-disallowing or unknown leaf -> accelerator error

The source creates the Control, Meta, and Control-Meta digit/minus/infinity variants in Standard arguments; the unmodified digit, minus, and infinity entries belong to the separate Unshifted Arguments table and are not effective here. On an accelerator error the standalone reader beeps, clears accelerator input, displays the diagnostic, and reprompts. Any other unknown idle character follows the same path. In particular, colon is not a hidden full-command prefix in this table. A presentation-produced command blip remains a separate valid input route.

The complete standalone pointer and menu tree is:

displayed query value
├─ exact unmodified Left / Select -> replace from empty typed input
├─ exact unmodified Middle / Select-and-Edit -> edit from printed old value
├─ exact Shift-Middle / Remove -> reset through query command
└─ exact unmodified Right / Menu -> generic Operation menu
   └─ offer applicable replace, edit, and remove handlers

displayed enumerated choice
├─ exact unmodified Left / Select -> choose semantic choice
└─ exact unmodified Right / Menu -> generic Operation menu containing choose

compatible displayed sample
├─ exact unmodified Left / Select -> copy sample into matching query
└─ exact unmodified Right / Menu -> generic Operation menu containing use-sample

displayed command button
├─ exact unmodified Left / Select -> run continuation and resynchronize
└─ exact unmodified Right / Menu -> generic Operation menu containing button action

Done or Abort command-menu cell / inline exit presentation
├─ exact unmodified Left -> execute zero-argument command
├─ exact unmodified Right -> execute the same zero-argument command
└─ Middle or any modified raw gesture -> no command-menu handler

Every translator above defaults to menu inclusion, so Right is generic handler-menu resolution rather than a second direct translator. Direct gesture matching is exact: the selected Dynamic Windows table has 32 modifier-bit states for each of three buttons, and a handler for Select does not match a modified Left event merely because Left is present. All raw states not named above continue through generic Dynamic Windows handler resolution and otherwise become a dead-blip/beep result.

The TV mouse encoder chooses the highest newly pressed button bit, so a simultaneous Left+Middle transition reaches Middle and any simultaneous transition containing Right reaches Right. Sequential chords are separate newly-down transitions. The same encoder represents a double click by setting the Shift bit. Consequently double Middle is indistinguishable at this boundary from Shift-Middle and reaches Remove; double Left is Shift-Left and has no Accepting Values direct handler. A conforming test MUST inject logical/raw events rather than assume host toolkit double-click semantics.

Selecting a query leaves the idle accelerator reader and enters typed ACCEPT for that query. At that point the complete Input Editor map above becomes effective only after the query's activation, rescan, completion, command, blip, and per-call editor overlays. Return and End are the ordinary Accept activation characters unless a specific presentation type overrides them; completion types additionally consume the completion gestures specified above. Successful parsing updates the query; full rubout or correction returns through the query editor rather than being mistaken for an idle form accelerator.

Pane-based Accept Values reuses the query/redisplay substrate but routes commands through the owning program. The base accept-values-pane table adds the value, choice, and command-button presentation translators but no keyboard accelerators. The optional accept-values-pane-with-keyboard-commands table adds exactly Space, C-E, C-D, C-N, C-P, C-F, and C-B, with the same cursor semantics and no echo. It inherits only accept-values-pane; Refresh, Help, Done, Abort, scrolling, and argument prefixes exist only when the owning program explicitly contributes them. After a pane command it MUST resynchronize owning program state.

Runtime observation: the preserved Genera 8.5 world rejected an expression entered while a Boolean field owned the input context, redisplayed after correction, changed the mouse documentation over the Abort presentation, and returned without applying options after pointer selection. This bounded scholarly claim establishes typed field input and presentation-sensitive abort, not every query type. Portable provenance and the image-specific rightsholder/fair-use analysis are in the Genera screenshot asset catalog; the image is evidence, not decoration or a runtime dump.

Evidence: G85-SRC, accept-values.lisp.~244~:105-1797, plus cp/read-accelerated-command.lisp.~142~:55-831, cp/substrate-commands.lisp.~6~:99-299, dynamic-windows/dynamic-input.lisp.~498~:250-311,1160-1204, and window/mouse.lisp.~472~:631-700; G8-MAN independently documents prompt/query identity, EQUAL comparison, conditional queries, and formatted query output. Boolean correction and Abort are G85-RUN; changed-default resynchronization, every edit placement, command buttons, all 96 raw modifier/button states, zero-count choice motion, and non-Dynamic/serial fallbacks remain TODO-RUNTIME oracle obligations.

menu-program

The reusable menu program accepts arbitrary semantic choices. Pointer Select returns the recorded choice object. Typed characters build a case-insensitive prefix; next/previous navigation moves the highlighted match; End returns it; Rubout and Clear Input edit the prefix; Help reports generated controls; Abort exits without a choice. Prefix state and highlight MUST remain synchronized after the choice set changes.

reorder-sequence

Each element is a presentation. Holding Select and dragging an item vertically moves it as the pointer crosses recorded item regions. Done returns the reordered sequence; Abort returns no committed result. The operation uses a working sequence so abort cannot partially modify the caller's original unless the API explicitly documents destructive input.

alter-sequences

The client selects two working sequences, permits dragging within or between them, and returns one result per original candidate, using an unchanged marker where appropriate. Cross-sequence deletion and insertion MUST be atomic with respect to Abort so an element cannot disappear or be duplicated between the two mutations.

undo-program

The Graphics Editor source supplies a reusable, nonselectable Dynamic Windows program framework for undo. Its history is a branching chain/tree, not only two stacks. Each element has a name, monotonically assigned index, previous link, and either no next element, one next element, or a list of alternative next branches. Each concrete element MUST implement initialize, undo, and redo operations.

The current pointer denotes the last operation done or redone. Undo executes that element's inverse and moves to its previous element. Redo either follows the one next element or asks the user to choose among branches; an explicitly selected element can be the target of Undo or Redo. Commands include Undo, Redo, Skip to the next branch, and Clear Undo History. The UNDO-ELEMENT presentation type completes over names in the history; command-menu handlers use a direct gesture for the default step and a menu gesture to choose a specific element.

A reimplementation MUST preserve branches created after undoing and then performing a new action. It MUST not silently discard the former redo path unless a documented client policy requests linear history. Clearing history releases the full graph and sets first, last, and current to empty; the selected source does not reset the monotonic assignment index, so later entries keep increasing. Exact menu geometry, messages, and branch-choice interaction are TODO-RUNTIME.

MENU-PROGRAM resides in the program-framework implementation; reorder/alter clients load in the Dynamic Window Clients layer; UNDO-PROGRAM is a generic framework in the Graphics Editor source. Semantic equality and the supplied element presentation type govern identity; display strings are not a valid substitute. Evidence: selected component order at patch/system-452/system-452.component-dir.~10~:453-457, client definitions in define-program-framework.lisp.~332~, reorder-sequence.lisp.~10~, and graphic-editor/undo.lisp.~16~:56-323, and public client descriptions in G8-MAN. Standalone synthetic sessions for all four remain TODO-RUNTIME.

D5 public API closure

For D5, the implementation MUST publish a machine-readable manifest that gives the historical package and symbol, operator kind, complete lambda list or macro grammar, defaults, accepted options, return values, conditions and restarts, and the D0-D4 semantic operation implemented by each public entry. Public manual metadata should be the first source for public interfaces; installed-source metadata can identify System 452.22 additions or differences without publishing implementation bodies.

D5 conformance MAY be claimed for a declared subset only when every public interface used by that subset has a complete manifest entry and a black-box source-compatibility test. It MUST NOT be generalized from one compiling demonstration to the complete Dynamic Windows API. Exact private binary encodings, QFASL compatibility, and Ivory object layout require separately named profiles even after D5 closes.

Selected System 452.22 module coverage

The component directory is a load-selection witness, not proof that every selected module has a separate public contract. This matrix prevents a selected module from silently disappearing from the reconstruction boundary. Normative means this page states its D0-D4 semantic contract. Partial means only the named behavior is in the base profile; the remaining public surface needs a subprofile or D5 closure. Infrastructure means no independent user-visible contract has yet been established.

Coverage evidence: G85-SRC component selection at patch/system-452/system-452.component-dir.~10~:370-457. This matrix describes coverage status only; it does not reproduce or characterize an uninspected module by its name alone.

D0 substrate tests

Handler tests

D1 command tests

D2 output and redisplay tests

D3 framework tests

D4 client tests