From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10175 invoked by alias); 1 Mar 2014 22:50:21 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18539 Received: (qmail 9814 invoked from network); 1 Mar 2014 22:50:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7yQJadoswWp7FqpdzTi4AvtdA92WNium9SV65Dldb8g=; b=yTGbwBl6IIPSfc0s5H+9S/qBGaa6Ft6s9qgebHzNIiU/Ngz/8BTI+V43kWhdKQINRo z6wHTUdD57rHPWbH+g2q94IuG0x7y0TV0oK0EBTJjDhJj5yvYzAWtXyJ3dIvf6bSWXer bgQGPy3D9oxfCIgXalD3dByQGCj9CkrDWkdVi9qVNjef6Ng6V5VpENok2k71koVrFUEU 0rt/LSaFXCw2D8ZssG9dVK5coAdGeMFTHIv7zzaEIE+B3GZ0mQgBQwpYIMU50GKmlcFw 9qSZm0O5nDVUM9BLoUt+PjlKefw3gvkedH6cYW+xg6khryJr6S0IWxQbWiCCAV1thrOv y6PQ== MIME-Version: 1.0 X-Received: by 10.52.108.228 with SMTP id hn4mr425402vdb.43.1393714209255; Sat, 01 Mar 2014 14:50:09 -0800 (PST) In-Reply-To: <5312469E.5080907@eastlink.ca> References: <140204073937.ZM21329@torch.brasslantern.com> <52F1146D.5020801@eastlink.ca> <140204194650.ZM21787@torch.brasslantern.com> <52F283E8.4050500@eastlink.ca> <530CB4E8.8050305@eastlink.ca> <140225094657.ZM2214@torch.brasslantern.com> <530CE01D.9080201@eastlink.ca> <140225112152.ZM2295@torch.brasslantern.com> <530CF1D5.2050805@eastlink.ca> <140226182921.ZM3650@torch.brasslantern.com> <530EC7EA.8020602@eastlink.ca> <530ECE6B.50605@eastlink.ca> <140228210859.ZM5878@torch.brasslantern.com> <5312469E.5080907@eastlink.ca> Date: Sat, 1 Mar 2014 17:50:09 -0500 Message-ID: Subject: Re: key codes table. From: shawn wilson To: Ray Andrews Cc: Zsh Users Content-Type: multipart/alternative; boundary=bcaec548a8e95c773904f39360cd --bcaec548a8e95c773904f39360cd Content-Type: text/plain; charset=UTF-8 If you want that chart, you should be able to come up with a script that gets key bindings for \x00 - \x255 (or more realistically 80~200 - printable characters) and we can run it through common environments? I think that's what you're looking for anyway? On Mar 1, 2014 3:45 PM, "Ray Andrews" wrote: > On 02/28/2014 09:08 PM, Bart Schaefer wrote: > >> Eventually Ray is going to regret asking me these questions ... >> > Eventually Bart is going to give up in despair ;-) > >> Unfortunately the set of key sequences you've listed here is likely >> very specific to the environment you just described. As you've noticed, >> it's not even the same for the console terminals on the same OS. >> > No surprise there. I know this is a layer cake sort of thing with > hardware/kernel/zsh/X/xfce/app each having their > own kick at the keyboard. Anyway, it was an interesting exercise seeing > what I have here on a grey colored PC runing debian/zsh/xfce in Canada on > Tuesday. > >> Do you begin to see why we don't bother attempting to create a static >> table of all this? >> > I sure do! Still some automated way of coughing it all up as a table would > be nice. It would > be good to know what KB resources one has at one's disposal in any given > situation, remembering that it > could all change on Wednesday. That's what I was trying to accomplish. > Sorta like 'bindkey' shows what bindings are currently active, one might > have a dump of all possible bindings in the current environment. One might > then plan some sort of > personal coordinated keyboard layout that can plan around existing keys. > Mean time, I wrote a sort of > souped up 'showkey' > > pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ . ./x > > Type the keycode you want, then 'space' to see what it is bound to. > TAB exits the program. > > Key ... ^A > "^A" bound to: beginning-of-line > Key ... ^Z > (unused) > Key ... ^Zc > (unused) > Key ... ^Xc > "^Xc" bound to: _correct_word > Key ... ^Xnuns > "^Xnuns" bound to: "Nuns fret not at their convents narrow > room" > Key ... z > > output (cat /tmp/keys_tmp): > > "^A" bound to: beginning-of-line > (unused) > (unused) > "^Xc" bound to: _correct_word > "^Xnuns" bound to: "Nuns fret not at their convents narrow > room" > > pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ l > > ============================== > > > Could be an artifact of some other (possibly historical/disused) keyboard > layout such as the Sun keyboard that zkbd partly supports. Could even be > related to the wiring of the circuit board in some keyboard from the 80s > that became a defacto standard. A lot of this stuff was invented when > most Unix keyboards were an integral part of the terminal device and > there was no such thing as separate, independent monitor and keyboard. > > Eventually those things will be lost in the mists of time. It's hardly > important. > >> } Don't forget that: >> } >> } /-Shift-Ctrl = Bksp = '^?' >> >> Actually that is ASCII DELete not Backspace. Backspace is ^H ... but >> of course the Del key might send any of ^? or ^H or ^[[3~ etc., and >> the key labeled Backspace often sends ^?. >> > Mere anarchy. > >> >> Consider all the layers that a key press has to pass through to reach >> your shell or other program running in your xterm: >> >> - Circuit board in the keyboard itself >> - Motherboard or graphics card hardware >> - BIOS >> - Operating system device driver >> - Input event device >> [< >> - X server event handler >> - Session manager >> - Desktop manager >> - Window manager >> - Terminal emulator >> >] >> - (Pseudo-) TTY device >> - Kernel I/O layer >> - User-space system call interface >> > I AM sorry I asked ;-) > >> (In DOS, roughly speaking, things go directly from the OS driver to >> the I/O layer and skip everything I listed in between, which is why >> there is so little variation or complexity in behavior.) >> > That's right. I actually understood all this stuff in DOS. Now we have > 'XKB' which the Devil > himself probably does not understand. > .... > >> As for whether the assignments are changeable: yes! At effectively >> every layer from the session manager down to the terminal emulator; >> though exactly what they are allowed to do at each layer varies, >> and you might have to change several layers to get a particular key >> combination to be visible to the terminal emulator, which may break >> something else in ways you don't expect. >> >> Does that clear things up? :-) >> >> That made it about as clear as it could be, which is still somewhat > beyond my abilities. Sheesh, > this started when I noticed that the key between my left Ctrl and Alt keys > (which currently outputs '<') > produces a different scan code than the other '<' which is the shifted > comma key, > and I was wondering if I could morph it into a 'Meta' key. And never in my > life have I been so sorry > that I looked into something ;-) I know how Pandora felt. This is not > something that an ordinary mortal > should get involved with. > > --bcaec548a8e95c773904f39360cd--