rr2b+@ANDREW.CMU.EDU (Robert Andrew Ryan) (12/13/90)
Argh, that should teach me to respond at 4AM :-) The second "textview" in my post should be "compchar" so the line would read like: addkey compchar-compose \ea textview compchar inherit "a:" Excerpts from internet.info-andrew: 12-Dec-90 X11 key bindings, once agai.. Juergen Henke@qt.IPA.FhG (1310+0) > O.k., one more try: Is there a way to tell ATK NOT to map the Meta-key > to the Escape-key ? Currently, no. We could modify the X code to determine the key sequence to send from a preference though (with the default being the Escape character of course). Chances of seeing this change in patch 8 are probably low to nil, but good for patch 9. -Rob Ryan Student Programmer, ATK group
bader+@ANDREW.CMU.EDU (Miles Bader) (12/13/90)
Robert Andrew Ryan <rr2b+@andrew.cmu.edu> writes: > Currently, no. We could modify the X code to determine the key sequence > to send from a preference though (with the default being the Escape > character of course). Chances of seeing this change in patch 8 are > probably low to nil, but good for patch 9. Or maybe set the high bit? -Miles
rr2b+@ANDREW.CMU.EDU (Robert Andrew Ryan) (12/13/90)
Excerpts from internet.info-andrew: 12-Dec-90 Re: X11 key bindings, once
.. Miles Bader (346)
> Or maybe set the high bit?
This could also be done, but I see two problems with this:
1. Meta-control-@ would not be representable (due to the way the end of
a keybinding is indicated), granted this is a minor concern but
something which would need to be known.
2. The syntax for specifying Meta-characters in the init files would be
quite cumbersome (the octal representation of the characters would have
to be used).
I guess ideally both options would be available, any ideas on how
Meta-characters should be represented in the .*init files? (besides the
octal)
Thanks,
-Rob Ryan
Student Programmer, ATK groupguy@auspex.auspex.com (Guy Harris) (12/20/90)
>Or maybe set the high bit?
Let's see, the "key" parameter to procedures such as "userKey" is a
"long"; setting the high bit - namely, 0x80000000 - seems ok....
Now, if by "the high bit" you meant the high bit of a "char", thanks but
no thanks; setting the high bit on a lower-case "b", for instance, gives
you "a with circumflex accent", which is probably not what you want....
I'd vote for having a keystroke event's code having, say, a character in
the lower 8 (or maybe 16) bits, and a bunch of modifier flags (Meta and
Alt, at least; probably Shift and Ctrl and others as well, at least for
keys where Shift and Ctrl would otherwise have no effect) in the upper
bits.
The interaction manager for window systems such as WM with limited
notions of "what to do with modifier bits" would never set those bits,
but the interaction manager for window systems that handle modifier bits
better, e.g. X11 and Presentation Manager, could set them. Those
window systems could still, by default, ignore the Alt key, treat the
Meta key as a request to generate a <ESC>-key event before the regular
key event, and never add in Shift or Ctrl as modifier flags.
The key binding syntax could be extended to let you bind, say,
Meta+Shift+Delete to an inset's "cut" function (to pick a purely
hypothetical example :-) :-) :-)). It could also let you specify
arbitrary keysym names in X, to let you bind to keys that Andrew doesn't
have built-in knowledge of; a similar set of names could be constructed
for, say, Presentation Manager.
With the defaults listed above, you could still pretend that other
window systems have a keyboard input model like WM's, and the default
key bindings would be unchanged, but if you have a window system with a
more capable keyboard input model, you could set things up to use it.
(This would also involve having the X interaction manager, for example,
shut off any calls in the set of "XRebindKeysym()" calls if the keysym
in question was directly bound to a procedure.)