This commit is contained in:
gferg 2002-02-17 18:35:57 +00:00
parent 003e7cb61a
commit 3144bcb4bd
1 changed files with 100 additions and 25 deletions

View File

@ -13,6 +13,11 @@
</author> </author>
<revhistory> <revhistory>
<revision>
<revnumber>v1.6</revnumber>
<date>19 Jan 2002</date>
<revremark>Included many comments from Alex Boldt and Chung-Rui Kao.</revremark>
</revision>
<revision> <revision>
<revnumber>v1.5</revnumber> <revnumber>v1.5</revnumber>
<date>3 May 2000</date> <date>3 May 2000</date>
@ -53,6 +58,7 @@
<sect1 id="intro"> <sect1 id="intro">
<title>Introduction</title> <title>Introduction</title>
<para>Every Linux user has been sooner or later trapped in a situation in <para>Every Linux user has been sooner or later trapped in a situation in
which having working <keycap>Backspace</keycap> and <keycap>Delete</keycap> which having working <keycap>Backspace</keycap> and <keycap>Delete</keycap>
@ -88,8 +94,8 @@
databases correspond even less to the terminal emulators they are supposed databases correspond even less to the terminal emulators they are supposed
to describe. To set a firm ground for the following discussion, we assume to describe. To set a firm ground for the following discussion, we assume
basically as correct settings the ones proposed in the <ulink basically as correct settings the ones proposed in the <ulink
url="http://www.debian.org/doc/debian-policy/ch3.html#s3.8">Debian keyboard url="http://www.debian.org/doc/debian-policy/">Debian keyboard
guidelines</ulink>.</para> policy</ulink>.</para>
</note> </note>
</sect1> </sect1>
@ -117,15 +123,17 @@
<para>The keycodes are translated by the keyboard library into a <para>The keycodes are translated by the keyboard library into a
<firstterm>keyboard symbol (keysym)</firstterm> using the keyboard <firstterm>keyboard symbol (keysym)</firstterm> using the keyboard
definition loaded by the user. If you look into your keyboard database definition loaded by the user. If you look into your keyboard database
(e.g., under Red Hat Linux, in <filename>/usr/lib/kbd/</filename>), (e.g., in <filename>/lib/kbd/</filename>), you'll discover several
you'll discover several definitions for different computers, different definitions for different computers, different layouts and possibly
layouts and possibly different interpretations of the same keys (e.g., different interpretations of the same keys (e.g., one could desire that
one could desire that the two <keycap>Alt</keycap> keys really behave the two <keycap>Alt</keycap> keys really behave as distinct
as distinct modifiers). The Linux console keyboard layout assigns modifiers). The Linux console keyboard layout assigns keysym
keysym <keysym>Delete</keysym> to keycode 14 and keysym <keysym>Delete</keysym> to keycode 14 and keysym
<keysym>Remove</keysym> to keycode 111. This may seem strange, but the <keysym>Remove</keysym> to keycode 111. This may seem strange, but the
Linux console emulates a VT100 terminal, and this is the way things Linux console emulates a VT100 terminal, and this is the way things
work in that realm.</para> work in that realm.<footnote><para>This claim has been
asserted/disputed several times commenting this document. If you have
any definitive information on this subject, please write me.</para></footnote></para>
</listitem> </listitem>
<listitem> <listitem>
@ -147,7 +155,15 @@
into a <firstterm>key capability</firstterm>. This goal is reached by a into a <firstterm>key capability</firstterm>. This goal is reached by a
<firstterm>terminal database</firstterm>, which contains, for each kind <firstterm>terminal database</firstterm>, which contains, for each kind
of terminal, a reverse mapping from sequences of characters to key of terminal, a reverse mapping from sequences of characters to key
capabilities (which are essentially a subset of the keysyms).</para> capabilities (which are essentially a subset of the keysyms).<footnote>
<para>Some programs rely on the terminal driver for input line editing,
such as deleting characters or words. With <command>stty</command>, you
can tell the terminal driver what character it should use to delete the
character to the left of the cursor (the <firstterm>erase</firstterm>
character). You can check your current settings with <command>stty
-a</command> and set them with <command>stty erase
<replaceable>character</replaceable></command>.</para></footnote></para>
<note> <note>
<para>Unfortunately, there are two <quote>standard</quote> terminal <para>Unfortunately, there are two <quote>standard</quote> terminal
@ -239,7 +255,7 @@
its own keysyms, which are much more varied and precise than the console 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 ones, and feeds them into applications (by the way, this is the reason why
<application>XEmacs</application> is not plagued by the problem: X <application>XEmacs</application> is not plagued by the problem: X
translates keycode 14 to keysym <keysym>BackSpace</keysym> and keycode 111 translates keycode 22 to keysym <keysym>BackSpace</keysym> and keycode 107
to keysym <keysym>Delete</keysym>, and then the user can easily assign to to keysym <keysym>Delete</keysym>, and then the user can easily assign to
those keysyms the desired behaviour). Of course, a terminal emulator those keysyms the desired behaviour). Of course, a terminal emulator
program (usually a VT100 emulator in the X world) must translate the program (usually a VT100 emulator in the X world) must translate the
@ -277,11 +293,15 @@ bash$ export TERM=gnome
<firstterm>standard</firstterm> a VT100 emulator behaving like the console, <firstterm>standard</firstterm> a VT100 emulator behaving like the console,
and <firstterm>deviant</firstterm> one that emits <symbol>BS</symbol> for and <firstterm>deviant</firstterm> one that emits <symbol>BS</symbol> for
<keycap>Backspace</keycap> and <symbol>DEL</symbol> for <keycap>Backspace</keycap> and <symbol>DEL</symbol> for
<keycap>Delete</keycap>. Thus, for instance, <keycap>Delete</keycap>.<footnote><para>Also these definitions have been
<application>xterm</application> has always been standard in the Debian asserted/disputed several times commenting this document. If you have any
distribution, while it switched a couple of times from standard to deviant definitive information on this subject, please write me.</para></footnote>
and viceversa in Red Hat; the behaviour of Thus, for instance, <application>xterm</application> has always been
<application>gnome-terminal</application> is even more erratic.</para> standard in the Debian distribution, while it switched a couple of times
from standard to deviant and viceversa in Red Hat; the behaviour of
<application>gnome-terminal</application> is even more erratic. See <xref
linkend="morehack"> for some information on how to turn a deviant terminal
into a standard one.</para>
</sect1> </sect1>
@ -364,11 +384,12 @@ a deviant one.
<para>However, <application>gnome-terminal</application> uses by <para>However, <application>gnome-terminal</application> uses by
default the same entry as <application>xterm</application>, so if one default the same entry as <application>xterm</application>, so if one
is deviant and the other one is not you will need to find a way to tell is deviant and the other one is not you will need to find a way to tell
them apart. Theoretically, the option <literal>termname</literal> of them apart. The option <literal>termname</literal> of
<application>gnome-terminal</application> should allow the user to set <application>gnome-terminal</application> allows the user to set the
the <envar>TERM</envar> variable to a more sensible name. However, as <envar>TERM</envar> variable to a more sensible name. However, in older
of <application>gnome-terminal</application> 1.2.1 the option does not versions of <application>gnome-terminal</application> the option does
work.</para> not work. Moreover, sometimes it is not easy to modify the way
<application>gnome-terminal</application> is started.</para>
<para>A good idea here is to exploit the fact that <para>A good idea here is to exploit the fact that
<application>gnome-terminal</application> sets the <application>gnome-terminal</application> sets the
@ -632,6 +653,59 @@ generate it.
</note> </note>
</sect1> </sect1>
<sect1 id="morehack">
<title>More Hacking</title>
<para>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.</para>
<para>It could happen that, for some reason, what I said talking about
<link linkend="x">X</link> is not true, that is, X does
<emphasis>not</emphasis> translate keycode 22 to keysym
<keysym>BackSpace</keysym> and keycode 107 to keysym
<keysym>Delete</keysym> (or even that, on your particular keyboard, the
keycodes associated to <keycap>Backspace</keycap>/<keycap>Delete</keycap>
are not 22 and 107). To be sure of that, you need to use
<command>xev</command>, 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 <command>xmodmap</command>, a command that lets you change many
settings related to X keyboard handling. For instance,
<screen>
xmodmap -e "keycode 22 = BackSpace"
xmodmap -e "keycode 107 = Delete"
</screen>
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 <varname>vt100.backArrowKey</varname>,
<varname>vt100.translations</varname> and <varname>ttyModes</varname> of
<application>xterm</application> (and similar terminal applications) in the
configuration file <filename>~/.Xdefaults</filename>. One
possibility, for instance, is
<programlisting>
XTerm.VT100.Translations: \
&lt;Key>BackSpace: string(0x7F)\n\
&lt;Key>Delete: string("\033[3~")
</programlisting>
You should take a look at the <application>xterm</application> man page for
more information.</para>
<para>The program that does for the console what <command>xev</command>
does for X is <command>showkeys</command>: it will dump the console
keycodes of the keys you press. Combining <command>showkeys</command> with
<command>dumpkeys</command>, which will print on standard output the
console keymap, you can easily fix mismatches between keycodes and
keysyms. Analogously to <command>xmodmap</command>,
<command>loadkeys</command> 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 <filename>/lib/kbd</filename>).</para>
</sect1>
<sect1 id="concl"> <sect1 id="concl">
<title>Conclusions</title> <title>Conclusions</title>
@ -639,11 +713,12 @@ generate it.
of deleting text you wrote (however, they do not help in creating other of deleting text you wrote (however, they do not help in creating other
text <literal>:)</literal>).</para> text <literal>:)</literal>).</para>
<para>There is a small bug in the whole setting: if you start <para>There is a small bug in the whole setting: if you're using the
<envar>COLORTERM</envar> trick and you start
<application>xterm</application> from <application>xterm</application> from
<application>gnome-terminal</application>, it will get <envar>TERM</envar> <application>gnome-terminal</application>, the former will get
set to <literal>gnome</literal>. This inconvenience is, of course, <envar>TERM</envar> set to <literal>gnome</literal>. This inconvenience is,
harmless, and it will be solved as soon as it will be possible to start of course, mostly harmless, and does not occur if you simply started
<application>gnome-terminal</application> with <envar>TERM</envar> suitably <application>gnome-terminal</application> with <envar>TERM</envar> suitably
set.</para> set.</para>