Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  bugs with keybindings
Message-ID: <9103221144.AA00390@lightning.McRCIM.McGill.EDU>
Date: 22 Mar 91 11:44:23 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 48

> clear mod1
> keysym Meta_L = Mode_switch
> clear mod3
> add mod3 = Mode_switch

Looks fine.

> Now I want to have the Meta_R key to have the same effect so:
> keysym Meta_R = Mode_switch

> Both keys should be generating the same things, but they don't!

Ah, but you haven't tied the right-hand meta key's keycode to mod3.
The xmodmap syntax obscures it, but modifiers are tied to keycodes, not
keysyms.

> the left key is considered to be a modifier, but not Meta_R.  No
> amount of clear mod3 and add mod3 = Mode_switch seem to work.

Odd; I guess xmodmap is being excessively stupid.

> A few hours later, a new twist:
> keysym Mode_switch = Meta_R
> clear mod3
> add mod3 = Meta_R Mode_switch

Once you've done this, "keysym Meta_R = Mode_switch" should work.

> I tried to define the "Linefeed" key to be a caps lock:

> clear lock
> add lock = Linefeed

The Lock modifier interpretation varies.  Normally, if it is tied to a
keycode with the Caps_Lock keysym, it's caps-lock; if Shift_Lock, it's
shift-lock.  There is no standard interpretation for the Lock modifier
when it's bound to a keycode whose keysym is Linefeed.

> Linefeed has no impact as a cap lock key BUT it does seem to affect
> the binding of the keys of tvtwm!

The Xlib in use ignores Lock/Linefeed, but tvtwm pays attention to the
modifier bit regardless of the keysym - that's how I'd interpret that.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu