Re: fixing backspace and delete
On 22 Apr, Petr Kolar wrote:
method 1: remapping
>> >> system keymap, setting keycode 14 to backspace and keycode 111 to
>> >> delete.
method 2: leaving it as it is
>> > Is not better to map keycode 14 to delete and keycode 111 to remove (and
>> > later to "\e[3~") and let Ctrl-H to be backspace? Does eg. 'info' work with
>> > your setting?
> In principle both these mappings are possible. The former was
> described in Linux Journal from June 1997 (pages 52-63), the latter
> in ftp://ftp.linux.org.uk/pub/linux/docs/HOWTO/mini/Key-Setup .
> The latter has the advantage that it is possible to distinguish
> the key Ctrl-H (help in some applications) and the key Backspace
> ('delete a char left from the cursor' or 'page up'). Linux kernel
> use it by default (see /usr/src/linux/drivers/char/defkeymap.map).
> And also it looks better to have something like
> bindkey "\e[1~" beginning-of-the-line # Home
> bindkey "\e[2~" overwrite-mode # Insert
> bindkey "\e[3~" delete-char # Delete
> bindkey "\e[4~" end-of-line # End
> in /etc/csh.cshrc (and something similar in other configuration
> files) than when among these lines would appear
> bindkey "^?" delete-char # Delete
[snip keys in info]
> I think the Backspace key should work in all applications; and Delete,
> Home, End etc. keys in every application which want to use them. And it
> is terrible that it is not already so with most distributions of Linux.
I couldn't agree more.
> 'ncftp is much nicer than ftp' is no argument.
I know, it wasn't meant as an argument, just a silly comment which I
will regret ever after. Following your line of thought, what kind of
argument is '...also it looks better...'?
>> If you map keycode 14 to delete, I think the delete button will
>> generate ^H.
> NO! If you map keycode 14 to delete, the Backspace button (on a PC
> keyboard; keycode 14) will generate ^?.
You're right, however, I am not sure what you mean by letting Ctrl-H
[snip disadvantages of leaving keymap alone]
> xmodmap -e 'keycode 22 = BackSpace'
> is enough for X. And I am sure most application would not have any problems
> with this mapping.
X is not the problem, whether the keymap is changed or not. However, as
mentioned before, while you can get every single application to work the
way you propose, the problem is to get them all to work at the same
time. Try getting joe, pico and pine to work, on the console, and in an
xterm. I can't, since joe relies on xterm's Xresources which
unfortunately break pico/pine. While delete in xterm can be configured
without Xresources, this breaks joe. On the console everything can be
easily made to work, no problem. Actually, if we can find a way to work
around this problem it would be the easiest way to go. A possibility is
to use a different joerc dependent on TERM, but joe doesn't seem to
have an option for specifying an alternate joerc (even if it could it
would be an extremely ugly workaround). Maybe the JOETERM variable can
be used. Can anyone look at this?
If the problem mentioned above can be fixed (without losing a
correctly deleting delete key in xterm) then I think the method you
propose (method 2) is to be preffered.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com