[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#2313: xterm keymapping problems suspected

Michael Meskes <meskes@Informatik.RWTH-Aachen.DE> said:

> Bill Mitchell writes:
> > It looks to me as if the /usr/lib/kbd/keytables/*.map files should have:
> > 
> >   keycode 14 = Backspace             Backspace
> >   keycode 111 = Delete
> > 
> > And that "stty erase ^H" should be set up by default.  Those changes
> > make the linux VC operate pretty much as I'd expect, and pretty much
> > as MSDOS users might expect  Where it operates not as I expect is with
> I don't agree. Historically the ^? is the Unix BackSpace, ^H has just been
> taken over from DOS. Why do we have to do it in a way a DOS user would
> expect. IMO we should do it in a way a Unix user would expect. In fact I
> don't think a DOS user worries about the codes produced but only about the
> result. A BackSpace keypress should delete the character to the left while a
> Delete press should delete the actual character.

I don't agree.  Historically, ^? is the intr key.  I think '@' was
originally the erase key.  I guess the difference between our
respective views of history isthe placement of the dividing line
between history and prehistor ;-).  By way of clarification, my
remark about MSDOS users above comes from a concern that a large
percentage of new linux users are likely to be recent converts
from MSDOS.

I tend to set the erase char according to the layout of the
keyboard I'm using -- setting it to whichever is more convenient
between the BS and DEL keys; and I set ^C to be the intr key.  Don't
forget that not all users will necessarily be using the console keyboard
on a *nix system, as they normally would be on an MSDOS machine.

> [...]
> Also, where's the problem allowing the delete key to return ESC [3~?

As long as the X and non-X keymappings and the terminfo capability
files are all in sync, I'd say that the only problem would be the
difference between linux console users (DEL key produces ESC [3~?)
and rlogin'd or serial-connected users (DEL key probably produces
a DEL char) running applications which do raw IO and interpret
keystrokes directly instead of using libncurses.  Such programs would
probably expect the DEL key to produce a DEL character instead of
that escape sequence.

Reply to: