Page 227	Table of Contents	Index	Page 229
	Chapters
	1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 A, B, C, D, E

CHAPTER 23. PRESENTATION TYPES

the canonical names above (using string-equal to do the comparison).

In the body of the translator (or the tester), the positional object argument will be bound to
the presentation's object. The named arguments presentation will be bound to the presentation
that was clicked on, context-type will be bound to the presentation type of the context that
actually matched, frame will be bound to the application frame that is currently active (usually
*application-frame*), event will be bound to the pointer button event that the user used,
window will be bound to the window stream from which the event came, and x and y will be bound
to the x and y positions within window that the pointer was at when the event occurred. The
special variable *input-context* will be bound to the current input context. Note that, in many
implementations context-type and *input-context* will have dynamic extent, so programmers
should not store without first copying them.

body is the body of the translator, and is run in the context of the application. body may have
zero or more declarations as its first forms. It should return either one, two, or three values.
The first value is an object which must be presentation-typep of to-type, and the second value
is a presentation type that must be presentation-subtypep of to-type. The consequences are
unspecified if the object is not presentation-typep of to-type or the type is not presentation- subtypepof to-type. The first two returned values of body are used, in effect, as the returned
values for the call to accept that established the matching input context.

The third value returned by body must either be nil or a list of options (as keyword-value
pairs) that will be interpreted by accept. The only option defined so far is :echo, whose value
must be either true (the default) or false. If it is true, the object returned by the translator
will be "echoed" by accept, which will use presentation-replace-input to insert the textual
representation of the object into the input buffer. If it is false, the object will not be echoed.

None of define-presentation-translator's arguments is evaluated.

=> define-presentation-to-command-translator name (from-type command-name command-
table &key gesture tester documentation pointer-documentation menu priority echo) arglist &bodybody [Macro]
This is similar to define-presentation-translator, except that the to-type will be derived to
be the command named by command-name in the command table command-table. command-
name is the name of the command that this translator will translate to.

The echo option is a boolean value (the default is true) that indicates whether the command
line should be echoed when a user invokes the translator.

The other arguments to define-presentation-to-command-translator are the same as for
define-presentation-translator. Note that the tester for command translators is always
assumed to be definitive, so there is no :tester-definitive option. The default for pointer-
documentation is the string command-name with dash characters replaced by spaces, and each
word capitalized (as in add-command-to-command-table).

The body of the translator must return a list of the arguments to the command named by
command-name. body is run in the context of the application. The returned value of the body,
appended to the command name, are eventually passed to execute-frame-command. body may
have zero or more declarations as its first forms.

Page 227	Table of Contents	Index	Page 229
	Chapters
	1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 A, B, C, D, E