Re: fixing backspace and delete
In article <[🔎] 98Apr20.152137gmt.19761@gateway.dhi.dk> you write:
> The approach I use to get those #¤@% keys right is to remap the
> system keymap, setting keycode 14 to backspace and keycode 111 to
> delete. Not only is this in my opinion the way it should be (at least
> it's in accordance with the rest of the Unix world) it also works (for
> the programs I know of). From what I gather you think the same.
I certainly don't think the same, in fact I'm very worried about your
determination to *break* the keymap. (And it's not in accordance with
the rest of the Unix world either.)
Generally, the situation is much confused. Half-understood attempts to
accommodate various breakage and nested work-arounds have muddied the
waters. I'll try to explain. If I'm not coherent, please tell me and
I'll try again. This is import.
Typically a terminal has in the upper right corner of the main key block
a key that people expect to be bound to the function delete-previous-
character. Depending on the terminal, this key may be labeled
"Backspace", "<--", "<X|", "Delete", etc. A neutral term for it is
"rubout".
("delete-{next,previous}-character" and "rubout" are emacs-speak but I'm
*not* talking about emacs only. I just need to settle on some terms.)
A terminal keyboard may also have a special key people expect to be
bound to the function delete-next-character. This key may be labeled
"Delete", "Remove", "Erase Char", etc. (I'm not aware of a neutral
term.) Or, it may be simply missing.
Now, the Linux console strives to emulate a DEC VT220 terminal, because
the DEC terminal line is something of a standard in the Unix world,
especially in the BSD camp which has vastly influenced GNU and thus
Linux. The rubout key of the VT220, labeled "<X|", produces an ASCII DEL
(0x7F, ^?) character. The VT220 also has a key labeled "Remove", which
produces the sequence ESC [ 3 ~.
The VT220 itself is the successor to the VT100. The rubout key of the
VT100, labeled "<-" IIRC, also produces DEL. The VT100 didn't have a key
associated with delete-previous-character. The VT100 *did* have a key
labeled "Backspace" (or "BS" maybe) that generated ASCII BS (0x08, ^H),
but that key was in an awkward position and did not serve as rubout.
There are of course terminals whose rubout key produces an ASCII BS
(0x08) character. There also terminals whose left arrow key produces the
same character. Lots of breakage. Anyway, the rubout key on a VT100
series terminal produces a DEL, and if a terminal emulator doesn't, it
is broken.
On the shell level, the "stty erase" setting determines what character
is bound to delete-previous-character. (There is no stty setting for
delete-next-character.) The tty discipline sticks to what it finds
there.
The terminfo database also contains two capabilities for the keys that
people typically bind to delete-previous-character (kbs) and
delete-next-character (kdch1). The correct settings of these
capabilities for the VT220 terminal/the Linux console are kbs=\177,
kdch1=\E[3~.
Now let's move to X11.
There the rubout key (associated with delete-previous-character) should
produce the _keysym_ <BackSpace>. The key associated with
delete-next-character should produce the keysym <Delete>. Motif for
instance expects this. It is the usual mapping and everything in X
itself is fine until people start messing with it.
The culprit is xterm. xterm pretends to emulate a VT100 series terminal,
and actually does a pretty good job at it. However, it translates the
<BackSpace> keysym to the BS character and the <Delete> keysym to the
DEL character. This is at odds with what the respective keys return on a
VT220 or on the console. People then start mapping <Delete> to the
rubout key, which makes xterm return the expected character but confuses
Motif and other X applications. Instead, xterm can easily configured for
the correct behavior with these resource lines:
XTerm*ttyModes: erase ^?
XTerm*VT100.Translations: \
#override <Key>BackSpace: string(0x7f) \n\
<Key>Delete: string(0x1b) string("[3~")
This may be at odds with the xterm terminfo entry, which needs to be
corrected then.
Alternatively, you might decide to leave xterm's <BackSpace> -> BS and
<Delete> -> DEL mapping alone.
Advantage:
- If you telnet to a remote machine, the default xterm terminfo entry
will most likely use kbs=^H, kdch1=\177.
Disadvantages:
- You will have to deal with stubborn applications like emacs that
insist that only ^? is appropriate for deleting.
- There are different control characters for delete-{previous,next}-
character depending whether you're on the console or in an xterm.
Users seem to be mentally unable to cope with this.
--
Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de
See another pointless homepage at <URL:http://home.pages.de/~naddy/>.
--
To UNSUBSCRIBE, email to debian-i18n-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: