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

Re: help for editing text.

    Date: Tue, 29 Sep 1992 09:13 EDT
    From: Scott McKay <SWM@STONY-BROOK.SCRC.Symbolics.COM>

	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?

Well, as it turns out, CLIM 2.0 already seems to do this./

0,,
References:
Main Index | Thread Index