Note that Arguments and Symbols are only used in CompoundExprs, indeed they are a part of the definition of any Class of CompoundExprs.

Meddle's view of the displayed form of a CompoundExpr is that it can be thought of as consisting of Arguments and Symbols, where Symbols are fixed glyphs (e.g. an integral sign, a radical sign), and Arguments are, recursively, arbitrary Expressions. The implementation of this is, when we need the Expr corresponding to an Argument, to do a lookup in the subExprs list of the CompoundExpr using the tag for that argument given in the Argument list of the CompoundClass definition. On the one hand, this scheme of classifying the components of a notation as either Arguments or Symbol permits too much (e.g. in a function notation f(x), we can replace f by a/b to get nonsense, since f is an Argument in the function Expr class); on the other, since the hit detection mechanism does not allow for selection of Symbols of an Expression (its algorithm is: see if the hit occurs inside any Argument Expr, if so, return result of recursive call HitDetect[argumentExpr, position], else return thisExpr), which apparently people want to do.

Note that if the same symbol occurs multiple times, e.g. comma in f(a, b, c), then those have to be different declared symbols. The point is that each symbol and argument comprising a notation must be a distinct, nameable, box, which we will constrain appropriately to do the layout.

There are two extensions to the current scheme that might be helpful. First, allow initial assignment of Exprs other than Placeholder to Arguments. Then if there are obvious cases of current Symbols that one would like to be able to select, e.g. integral sign, make them Arguments with appropriate initial (Atomic) Exprs. Of course, this opens the way to new kinds of garbage, e.g. an Expr that CaminoReal thinks internally is an integral, but whose display form doesn't have an Integral sign anywhere because that Argument Expr has been replaced by some other Expr.

Would really be nice if the initial Exprs assigned to Arguments could be the results of procedure evaluations. This would allow the definition of "composed" Expr classes, e.g. matrix of partial derivatives, i.e. much richer templates. Ideally, user interface would allow users to just create the template using the Editor, then say "install it", and have CaminoReal do the necessary bookkeeping. (This opens issues of what "siblings" would mean in such templates, however; presumably the answer is: wrt order of leaves in a preorder tree traversal.)

A second extension might help with both current and future problems of introducing garbage. This would be, for Arguments of an Expression class (whether initially placeholder, or whether intially something more elaborate), to allow for "type" specification, i.e. imposition of rules that restrict the kinds of Expressions that a given Argument can be given as values. Note that the Domain-driven editing mode (i.e. you eval the current expr, put up the ops of its Domain, and specify Expression creation rather than Evaluation with the selected operator) accomplishes this.

At most one of the Arguments of a CompoundExpr can have the alias $hot? Is the notion of "selectable sibling of the hot arg" equivalent to the notions of "hottest" and "hot" that we want for the semantics of wrap: "the Expr being wrapped around replaces the hottest Arg, and the hot arg becomes the primary selection"?

We don't actuall have a grammar in our database. i.e. our (Compound) templates consist of ordered arglists. There is no built-in assumption that we will "see" certain characters in an (ordered) "input stream".

Note that selections are specified in terms of decorated parse trees, i.e. DisplayExprs. I.e. they are independent of their display in specific viewers.

The general idea is to maintain a global, across all the different ExprViewers that may exist at any one time, list of currently active selections. Besides its flavor, with each we store the Viewer containing it, and the selected DisplayExpr within that Viewer. Painting of the selection depends on finding exactly that DisplayExpr, i.e. by equality of pointers, in a walk down the Viewer's (overall) DisplayExpr.

The concept of whether or not a selection of a certain type is "active" or not?

ViewExprOpsImpl.GlobalSelections is a list of the currently active selections. Just because a flavor has an entry here, doesn't mean active; that true iff its value (of type Selection) is non—NIL and if active field TRUE.

A KB selection is really just a certain kind of "incremental" primary selection, i.e. "string of characters being typed in from the keyboard". When the screen shows a KB selection, it means that if the right sort of character is typed next, it will be concatenated to the current KB selection. When a "terminating action" occurs, the KB selection becomes the primary selection, which determines the semantics of the action.

At any point at which we have an active primary selection, a letter, digit, ?, or % causes us to start on a KB selection.

Wraps, whether SingleChar or MultiChar, always happen around the current Primary selection. If I have some a KB selection of type variable, integer, real, or symbol, then I have to explictly make it the Primary selection (^M) before I can do a MultiChar wrap around it. An exception to this is that a SingleChar wrap when there is a KB selection will treat it as though it were the Primary selection. If I have a KB selection and I try to do a MultiChar wrap without explicitly making the KB primary, the parser will just keep listening to the chars of my MultiChar template as though they were to be extending the current KB selection, e.g. the ?'s will get tossed.

The way MultiChar wraps work is: when you start it, you save the current active KB selection, if any, else the current active primary selection. Then you start building a new KB selection on top of whichever one you saved. When the template name is terminated, you replace the current KB with what was saved and make it Primary, then wrap the template around it.

Primary selection:

Copy selection:

Move selection:

Active keyboard selection (KB Selection):

Single Clicks:

Double Clicks:

Keyboard:

We are always replacing the Primary or Keyboard Selection by some Expr, i.e. it makes no sense to speak of replacing the Copy or Move selections.

If the Expr that we are replacing by is a template, we primary select its hot arg.

Defines types common to all modules. In the latest version, only two types are

defined: Style (font info), and

FormatClass: TYPE ~ {atom, paren, binaryOp, unaryOp, op, relation, over, matrix, radical, other};

This is a classification of user-defined operations into categories for use by formatting procedures.

Note that a FormatClass is an arg to MakeAtomClass (all the atom classes supply a value of "atom".)

Note also that MathDisplayExpr.Format sets the FormatClass of outer bounding RelBox to a new value.

Data abstraction for a BOX. A BOX is an immutable object.

A BOX is the basic building block for formatting expressions.

(Similar to TeX's concept of boxes and glue.)

Provides BOX constructors and selectors.

Provides operations for determining metrics about a box.

Provides some LIST operations for LIST OF BOX.

Defines procedure types for formatting, positioning, painting, and data conversion rules.

Defines types associated with alignment, positioning, and sizing.

Provides primitive procedures to align boxes: AlignHorizontal and AlignVertical.

Provides high-level procedures for automated positioning & composition:

Compose and ComposeMatrix.

Provides procedures for computing relative sizes: ComputeSize and VecFromSize.

Data abstraction for a mathematical expression, EXPR. An EXPR is an immutable

object which contains information about its subexpressions and their classes.

Provides EXPR constructors and selectors.

Provides parse/unparse operations for EXPR.

Provides LIST selector operation for LIST OF EXPR.

Also defines class types for atoms, compound exprs, and matrix exprs.

Classes contain information such as name and rules for formatting, painting, etc.

Provides constructors and selectors for these classes.

Data abstraction for a displayed mathematical expression, DisplayExpr. A DisplayExpr

is a mutable object which is an EXPR mapped to a viewer. It contains mutable

information about absolute box locations, etc.

Provides DisplayExpr constructors and selectors.

Provides conversion routines between EXPR <=> DisplayExpr.

Provides Copy, Format, Paint, Replace, Selection operations.

Provides an unparse operation to AlgebraStrutures/CaminoReal format.

The database of known types of mathematical expressions.

Loaded up by the InstallExprClasses modules.

Currently accessed only by the "Make Expr" procs in MathExpr (e.g. MakeCompoundExpr), and by the editing action procs (e.g. ReplaceWithOperator in ViewExprImpl).

Defines and registers classes and rules for many common math operations.

Provides high-level constuctors to combine EXPR's using these operations.

This is the right module to look at if you are defining new operations (notations).

Loads up the database.

Provides procedural abstractions called by ViewExpr to deal with selections and

paint "queue" operations.

This is the core of the MEDDLE user interface.

Defines and registers a new viewer class, $expr.

Parses keyboard and mouse events.

Handles menu events.

Handles copy/move/select events.

Handles all viewer trivia like PaintProc, NotifyProc, bi-scroller stuff, etc.

Provides high-level operations to create a MEDDLE viewer and set/get its contents.

Interface between MEDDLE and Tioga.

Defines and registers the Tioga CharacterArtwork class $MeddleExpr.

Registers (Commander) command "MeddleArtwork {on|off}" to enable/disable this feature.

Interface between MEDDLE and CaminoReal.

Provides high-level operations to create a MEDDLE viewer and set/get its contents.

Defines and registers (Commander) command "MeddleOpen {name}" to open a

new MEDDLE viewer from the CommandTool.