Page 243 Table of Contents Index Page 245
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 24. INPUT EDITING AND COMPLETION FACILITIES 

     ;; Else it was an input editing command (which has already been
     ;; processed), so continue looping
     ))
When a new gesture object is inserted into the input editor buffer, it is inserted at the insertion
pointer IP. If IP = FP, this is accomplished by a vector-push-extend-like operation on the
input buffer and FP, and then incrementing IP. If IP < FP, CLIM must first "make room"
for the new gesture in the input buffer, then insert the gesture at IP, then increment both IP
and FP.

When the user requests an input editor motion command, only the insertion pointer IP is
affected. Motion commands do not need to request a rescan operation.

When the user requests an input editor deletion command, the sequence of gesture objects at
IP are removed, and IP and FP must be modified to reflect the new state of the input buffer.
Deletion commands (and other commands that modify the input buffer) must call immediate-
rescan when they are done modifying the buffer.

CLIM implementations are free to put special objects in the input editor buffer, such as "noise
strings" and "accept results". A "noise string" is used to represent some sort of in-line prompt
and is never seen as input; the prompt-for-accept method may insert a noise string into the
input buffer. An "accept result" is an object in the input buffer that is used to represent
some object that was inserted into the input buffer (typically via a pointer gesture) that has no
readable representation (in the Lisp sense); presentation-replace-input may create accept
results. Noise strings are skipped over by input editing commands, and accept results are treated
as a single gesture.

=> interactive-stream-p object [Generic Function]
Returns true if object is an interactive stream, that is, a bidrectional stream intended for user
interactions. Otherwise it returns false. This is exactly the same function as in X3J13 Common
Lisp, except that in CLIM it is a generic function.

The input editor need only be fully implemented for interactive streams.

=> input-editing-stream [Protocol Class]
The protocol class that corresponds to an input editing stream. If you want to create a new class
that behaves like an input editing stream, it should be a subclass of input-editing-stream.
Subclasses of input-editing-stream must obey the input editing stream protocol.

=> input-editing-stream-p object [Function]
Returns true if object is an input editing stream (that is, a stream of the sort created by a call
to with-input-editing), otherwise returns false.

=> standard-input-editing-stream [Class]
The class that implements CLIM's standard input editor. This is the class of stream created by
calling with-input-editing.

Page 243 Table of Contents Index Page 245
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