Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!mcsun!ukc!acorn!ixi!clive From: clive@x.co.uk (Clive Feather) Newsgroups: comp.windows.x Subject: Re: How do I remap the keyboard? Message-ID: Date: 2 May 91 08:02:07 GMT References: <9104102309.AA00552@lightning.McRCIM.McGill.EDU> <24228@well.sf.ca.us> <22171@shlump.nac.dec.com> Reply-To: clive@x.co.uk (Clive D.W. Feather) Organization: IXI Limited, Cambridge, UK Lines: 117 In article <22171@shlump.nac.dec.com> lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: > The question about defining shift-comma and shift-dot got answered by > several people: > xmodmap keysym comma = comma less > xmodmap keysym period = period greater > I'd tried lots of guesses as to > what xmodmap's syntax was, and never guessed this. I also can't quite > correlate this with what xmodmap's manual page describes as its syntax. > I mean, why are "comma" and "period" replicated on both sides of the '='? > How does it know that I'm telling it to change shift-comma, say, rather > that just comma or ctrl-comma or meta-comma or ...? What the @#$@# *is* > the syntax of this little beastie? On the left hand side of the equals, you are telling it to change the key with a comma on it. This is a convenience for the user; the "correct" way to do this is to say "keycode 123 = ...". However, it isn't obvious what the number of the key is, and it will differ from keyboard to keyboard. So xmodmap offers to look it up for you. Any symbol on the key will do: on my keyboard, "keysym 4 = ..." and "keysym dollar = ..." are equivalent. On the right hand side, you are listing the symbols that you want to pretend are painted on the key. The rules for this are: symbol 1: unshifted key (comma/period in your example) symbol 2: shifted key (less/greater in your example) symbol 3: grouped key (see below) symbol 4: shifted and grouped key symbols 5 onwards: no standard interpretation The "group" key is a modifier (like shift or control) used to select alternate key definitions (for example, for an English/Cyrillic keyboard, or for APL). Rather than fixing "group" to a specific key (such as meta), it is the key which is a modifier key (use xmodmap -pm to look at this) and which has "ModeSwitch" as one of its keysyms. > One of the first things was to discover that when the > xterm manual page says "The xterm application reads the .Xdefaults file > during startup ..." it is lying through its teeth. I wasted a couple of > hours modifying .Xdefaults, and nothing I did had any effect whatsoever > on new xterms. I became suspicious, did a "ls -lu .Xdefaults", started a > new xterm, and repeated the "ls -lu", and verified that the access time > hadn't changed. So xterm doesn't open .Xdefaults at all. A bit more > experimenting verified that if I kill X off and restart it, xterm then > uses the contents of .Xdefaults. Thus .Xdefaults is cached inside the > X server, and xterm gets the info from there. This also explains why > xterm is to incredibly slow when started across a SLIP link; the entire > .Xdefaults file is stuffed across the link for every xterm. A line > monitor verifies this; you can see the data flow by. Sigh. This behaviour is caused because you are running xrdb(1) from your start-up file. This loads a copy of .Xdefaults on the server, in such a way that XOpenDisplay (the Xlib function) will see it and copy it into the application data space when opening the display. Xterm then sees that this has been done, and uses it instead of .Xdefaults. There are good reasons for this feature which I won't go into, but if you're using SLIP, then you want to disable it. Just remove the xrdb command from you start-up file. My copy of the xterm(1) manual entry (R4)does not mention .Xdefaults at all. Have a look at the section RESOURCES in the X(1) manual entry, which goes into this, mentioning xrdb(1). You should read the whole X(1) manual entry before using X. The appres(1) program might be of use to you, as well. > xterm*scrollBar: true > xterm*Translations: #override \ > F1 : string("You touched F1") \n\ > ... > KP_0 : string("You touched KP_0") \n\ > ... > KP_F2: string("KP_F2\\n") \n\ > ... > Help : string("You touched Help") [...] > Well, not really, since this strikes me > as incredibly bizarre syntax. I mean, why the '#' before the "override"? > Why the "\n\" at the end of the lines? Where is this explained? The \n puts a newline character into the *resource* entry, which causes the *translation* manager to see the end of one line, and the start of the next. The final backslash escapes out the newline for the *resource* manager, so that it doesn't see the lines as each being a new resource definition. The # is placed before the override to indicate that this is *not* a normal translation line: the translation table can begin directly with (say) "" (of course, the presence or absence of #override affects the semantics). You might just as well ask why C requires a # before "define", or Bourne shell a $ before a variable name. Translation tables are explained in an appendix to the Xt Toolkit Intrinsics manual. There probably ought to be a pointer in X(1). File a bug report with the Consortium. > Also, I'm blocked at what might be the most critical point: The above > definitions define strings consisting only of printable ASCII characters. > I need to get things like ESC and CR and NUL into the strings. So far, > all my attempts have failed. I tried putting them literally into the > quoted strings; I get off-the-wall error messages from xterm and the > keys don't get redefined at all. I tried all sorts of escape sequences > such as "\n", "\013", "#0A", , and "^J", and none of them generate the > bits I want. They just toss out the backslashes and produce the printable > chars inside the quotes. Try: Help : string("You are an")string(0x0d)string(0x0a)string(Idiot!) You can have any number of actions (the things that look like function calls) on the right hand side. There is an example of this in the xterm(1) manual entry, just before the heading OTHER FEATURES. -- Clive D.W. Feather | IXI Limited | If you lie to the compiler, clive@x.co.uk | 62-74 Burleigh St. | it will get its revenge. Phone: +44 223 462 131 | Cambridge CB1 1OJ | - Henry Spencer (USA: 1 800 XDESK 57) | United Kingdom |