CLIM mail archive
help for editing text.
Date: Tue, 29 Sep 1992 13:29 EDT
From: firstname.lastname@example.org (Bill York)
Date: Tue, 29 Sep 1992 09:13-0400
From: Scott McKay <SWM@STONY-BROOK.SCRC.Symbolics.COM>
I don't think CLIM can reliably detect when you ask for an activation
character that is the same as an IE command binding, because IE command
bindings are potentially per-stream and activation gestures are not
associated with a stream (which you could claim is a problem in itself).
Good problem! I'm going to ignore it for now.
I think I'll probably ignore it indefinitely, since it involves an
incompatible change to the macro. Grr. Oh well, it's been with us
since Dynamic Windows, so I bet that it will never cause any bugs.
I agree that the current behavior is undesirable, but I'm not sure
exactly what to do about it. I suspect that the proper thing to do is
for LOOKUP-INPUT-EDITOR-COMMAND to exit immediately if it finds a
character that is an activation or "blip" char, and simply not bother
trying to find an IE command for those. Does that sound agreeable to
As I said, the input editor already does check for activation
characters (see code excerpt from input-editor.lisp below) and doesn't
even call lookup-input-editor-command if it finds one. Is this a
local fix or something?
No, I think that Paul Weineke made this fix and sent it to me. I
installed it and forgot about it. But this is fixed in CLIM 2.0.
(defmethod interactive-stream-process-gesture ((istream interactive-stream-mixin) gesture type)
(with-slots (numeric-argument last-command-type command-state) istream
(cond ((characterp gesture)
;; The COMMAND-STATE slot holds the current IE command aarray,
;; and gets updated when we see a prefix characters (e.g., ESC)
(when (char= gesture #\return) (setq gesture #\newline))
(let ((command (unless (activation-character-p gesture)
(lookup-input-editor-command gesture command-state))))
(cond ((numberp command)
(cond ((null numeric-argument)
. . .)))))))))
Main Index |