From 3144bcb4bdad4f24b390574520ce83ff4b72e316 Mon Sep 17 00:00:00 2001 From: gferg <> Date: Sun, 17 Feb 2002 18:35:57 +0000 Subject: [PATCH] updated --- LDP/howto/docbook/BackspaceDelete.sgml | 125 ++++++++++++++++++++----- 1 file changed, 100 insertions(+), 25 deletions(-) diff --git a/LDP/howto/docbook/BackspaceDelete.sgml b/LDP/howto/docbook/BackspaceDelete.sgml index 7d3e3be0..c532c481 100644 --- a/LDP/howto/docbook/BackspaceDelete.sgml +++ b/LDP/howto/docbook/BackspaceDelete.sgml @@ -13,6 +13,11 @@ + + v1.6 + 19 Jan 2002 + Included many comments from Alex Boldt and Chung-Rui Kao. + v1.5 3 May 2000 @@ -53,6 +58,7 @@ Introduction + Every Linux user has been sooner or later trapped in a situation in which having working Backspace and Delete @@ -88,8 +94,8 @@ databases correspond even less to the terminal emulators they are supposed to describe. To set a firm ground for the following discussion, we assume basically as correct settings the ones proposed in the Debian keyboard - guidelines. + url="http://www.debian.org/doc/debian-policy/">Debian keyboard + policy. @@ -117,15 +123,17 @@ The keycodes are translated by the keyboard library into a keyboard symbol (keysym) using the keyboard definition loaded by the user. If you look into your keyboard database - (e.g., under Red Hat Linux, in /usr/lib/kbd/), - you'll discover several definitions for different computers, different - layouts and possibly different interpretations of the same keys (e.g., - one could desire that the two Alt keys really behave - as distinct modifiers). The Linux console keyboard layout assigns - keysym Delete to keycode 14 and keysym + (e.g., in /lib/kbd/), you'll discover several + definitions for different computers, different layouts and possibly + different interpretations of the same keys (e.g., one could desire that + the two Alt keys really behave as distinct + modifiers). The Linux console keyboard layout assigns keysym + Delete to keycode 14 and keysym Remove to keycode 111. This may seem strange, but the Linux console emulates a VT100 terminal, and this is the way things - work in that realm. + work in that realm.This claim has been + asserted/disputed several times commenting this document. If you have + any definitive information on this subject, please write me. @@ -147,7 +155,15 @@ into a key capability. This goal is reached by a terminal database, which contains, for each kind of terminal, a reverse mapping from sequences of characters to key - capabilities (which are essentially a subset of the keysyms). + capabilities (which are essentially a subset of the keysyms). + Some programs rely on the terminal driver for input line editing, + such as deleting characters or words. With stty, you + can tell the terminal driver what character it should use to delete the + character to the left of the cursor (the erase + character). You can check your current settings with stty + -a and set them with stty erase + character. + Unfortunately, there are two standard terminal @@ -239,7 +255,7 @@ its own keysyms, which are much more varied and precise than the console ones, and feeds them into applications (by the way, this is the reason why XEmacs is not plagued by the problem: X - translates keycode 14 to keysym BackSpace and keycode 111 + translates keycode 22 to keysym BackSpace and keycode 107 to keysym Delete, and then the user can easily assign to those keysyms the desired behaviour). Of course, a terminal emulator program (usually a VT100 emulator in the X world) must translate the @@ -277,11 +293,15 @@ bash$ export TERM=gnome standard a VT100 emulator behaving like the console, and deviant one that emits BS for Backspace and DEL for - Delete. Thus, for instance, - xterm has always been standard in the Debian - distribution, while it switched a couple of times from standard to deviant - and viceversa in Red Hat; the behaviour of - gnome-terminal is even more erratic. + Delete.Also these definitions have been + asserted/disputed several times commenting this document. If you have any + definitive information on this subject, please write me. + Thus, for instance, xterm has always been + standard in the Debian distribution, while it switched a couple of times + from standard to deviant and viceversa in Red Hat; the behaviour of + gnome-terminal is even more erratic. See for some information on how to turn a deviant terminal + into a standard one. @@ -364,11 +384,12 @@ a deviant one. However, gnome-terminal uses by default the same entry as xterm, so if one is deviant and the other one is not you will need to find a way to tell - them apart. Theoretically, the option termname of - gnome-terminal should allow the user to set - the TERM variable to a more sensible name. However, as - of gnome-terminal 1.2.1 the option does not - work. + them apart. The option termname of + gnome-terminal allows the user to set the + TERM variable to a more sensible name. However, in older + versions of gnome-terminal the option does + not work. Moreover, sometimes it is not easy to modify the way + gnome-terminal is started. A good idea here is to exploit the fact that gnome-terminal sets the @@ -632,6 +653,59 @@ generate it. + + More Hacking + + So, you're not happy with the information you got. In this case, + there is even more hacking you can do on the Backspace/Delete issue, using + suitable commands that get or set the way X and the console handle + keys. + + It could happen that, for some reason, what I said talking about + X is not true, that is, X does + not translate keycode 22 to keysym + BackSpace and keycode 107 to keysym + Delete (or even that, on your particular keyboard, the + keycodes associated to Backspace/Delete + are not 22 and 107). To be sure of that, you need to use + xev, a simple X application that will display the + keycode and keysym associated to the key you press. If anything goes wrong, + there are several ways you can fix the problem: the easy, temporary way is + to use xmodmap, a command that lets you change many + settings related to X keyboard handling. For instance, + +xmodmap -e "keycode 22 = BackSpace" +xmodmap -e "keycode 107 = Delete" + + will set correctly the keysyms (assuming that 22 and 107 are the correct + keycodes for you). In case you want to do some changes permanently, you can + play with the resources vt100.backArrowKey, + vt100.translations and ttyModes of + xterm (and similar terminal applications) in the +configuration file ~/.Xdefaults. One + possibility, for instance, is + +XTerm.VT100.Translations: \ + <Key>BackSpace: string(0x7F)\n\ + <Key>Delete: string("\033[3~") + + You should take a look at the xterm man page for + more information. + + The program that does for the console what xev + does for X is showkeys: it will dump the console + keycodes of the keys you press. Combining showkeys with + dumpkeys, which will print on standard output the + console keymap, you can easily fix mismatches between keycodes and + keysyms. Analogously to xmodmap, + loadkeys can then fix single associations, or load + entirely new console keymaps. With it, you can even change the string + associated to a given keysym. If you want to record these changes, you will + have to define a new keymap for the console (you should have a look at the + system keymaps, usually located in /lib/kbd). + + + Conclusions @@ -639,11 +713,12 @@ generate it. of deleting text you wrote (however, they do not help in creating other text :)). - There is a small bug in the whole setting: if you start + There is a small bug in the whole setting: if you're using the + COLORTERM trick and you start xterm from - gnome-terminal, it will get TERM - set to gnome. This inconvenience is, of course, - harmless, and it will be solved as soon as it will be possible to start + gnome-terminal, the former will get + TERM set to gnome. This inconvenience is, + of course, mostly harmless, and does not occur if you simply started gnome-terminal with TERM suitably set.