CLIM mail archive
[Prev][Next][Index][Thread]

Re: help for editing text.

    Date: Mon, 28 Sep 1992 18:05 EDT
    From: Jeff Morrill <jmorrill@BBN.COM>

      Date: Mon, 28 Sep 92 13:03:32 PDT
      From: Bill York <york%oakland-hills@lucid.com>

      I would be interested in the trace output from the following:
  
      (trace clim::interactive-stream-process-gesture)
  
    0: (CLIM::INTERACTIVE-STREAM-PROCESS-GESTURE #<CLIM::INPUT-EDITING-STREAM @ #x1333e0e>
	 #\CONTROL-\d NIL)
    0: returned NIL

    Looks like #\control-\d got "swallowed" as you say.  A little poking around shows
    that this is bound to COM-IE-DELETE-CHARACTER for my environment.

    If an activation character is not going to work, then clim should probably detect
    this and signal an error.  I would prefer, on the other hand, that
    activation characters always activate.  In this case, the activation character
    is the most important IE command because it means "done editing".

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).

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
everyone concerned?

0,,
Follow-Ups: References:
Main Index | Thread Index