Next: External API, Up: Drei
The reason for many of Drei's design decisions, and the complexity of some of the code, is due to the flexibility that Drei is meant to expose. Drei has to work as, at least, an input-editor, a text editor gadget and a simple pane. These three different uses have widely different semantics for reading input and performing redisplay - from passively being fed gestures in the input editor, to having to event handling and redisplay timing manually in the gadget version. Furthermore, Drei is extensible software, so we wished to make the differences between these three modus operandorum transparent to the extender (as much as possible at least, unfortunately the Law of Leaky Abstractions prevents us from reaching perfection). These two demands require the core Drei protocols, especially those pertaining to redisplay, gesture handling and accepting input from the user, to be customizable by the different specialized Drei classes.
We call a specific instance of the Drei editor substrate a Drei
instance. A Drei variant is a specific subclass of drei
that implements a specific kind of editor, such as an input-editor or a
gadget. A given Drei instance has a single buffer associated with it,
but this buffer need not be unique to the Drei instance, and may be
changed at any time. The Drei instance has two marks into the buffer,
called the top and bottom mark. These marks delimit the visible
region of the buffer - for some Drei variants, this is always the entire
buffer, while others may only have a smaller visible region. Note that
not all of the visible region necessarily is on display on the screen
(parts, or all, of it may be hidden due to scrolling, for example), but
nothing outside the visible region is on display, though remember that
the same buffer may be used in several Drei instances, and that each of
these instances may have their own idea about what the visible region
is. The Drei instance also maintains marks for the current point and
mark. This means that different Drei instances sharing the same
buffer may have different points and marks. Every Drei instance also has
a kill ring object which contains object sequences that have been
killed from the buffer, and can be yanked back in at the users
behest. These are generally not shared.
Every Drei instance is associated with an editor pane - this must be a CLIM stream pane that is used for redisplay (see Redisplay Protocol). This is not necessarily the same object as the Drei instance itself, but it can be.
For each Drei instance, Drei attempts to simulate an application
top-level loop with something called a pseudo command loop, and
binds a number of special variables appropriately. This is to make
command writing more convenient and similar across all Drei variants,
but it also means that any program that uses one of the low-level Drei
variants that do not to this, such as drei-pane, need to bind
these special variables themselves, or Drei commands are likely to
malfunction.