Bug#1724: unexpected keypress translations (fwd)
Bill Mitchell writes ("Re: Bug#1724: unexpected keypress translations (fwd)"):
> The program in question is ae. I thought I'd pass this on
> to you. ae uses raw keypress defs in the config file, leading
> to this problem. I'm guessing that may have been a size or
> complexity tradeoff. The keypresses in question are PC
> function keys, which generate different escape sequences
> at the non-X11 linux console and in an xterm.
Well, that won't work. How does ae drive the screen ? Whatever
library it's using for that will provide a facility for interpreting
(or at least determining) function key sequences.
I've reopened this bug and assigned it to the `ae' package.
Ian.
> ---------- Forwarded message ----------
> Date: Sun, 22 Oct 95 18:40 GMT
> From: Ian Jackson <ian@chiark.chu.cam.ac.uk>
> To: Bill Mitchell <mitchell@mdd.comm.mot.com>, debian-bugs-done@Pixar.com,
> Debian developers list <debian-devel@Pixar.com>
> Subject: Re: Bug#1724: unexpected keypress translations
>
> Bill Mitchell writes ("Bug#1724: unexpected keypress translations"):
> > I noticed today that keypress translations are different in an
> > xterm window than on a VC not running X. I'm really not sure
> > if this is a bug or a case of "you should have expected that",
> > but it caused a program expecting the VC-style keypress
> > translations to misbehave when it got unexpected keypress
> > translations in an xterm window. It seems to me that, unless
> > there's some good reason otherwise, default keypress translations
> > shouldn't change.
>
> You should have expected that. Different terminals have different
> escape sequences, and an xterm is not the same as a Linux console.
>
> I'm marking this bug as done.
>
> If you have a program that doesn't correctly use the terminal
> information databases (termcap or terminfo) to interpret keystroke
> escapes then that program is buggy.
>
> > To duplicate, type "cat -v", F1, ^D in a VC; observe the results;
> > startx; and do the same thing in an xterm. I know that TERM=linux
> > doesn't work right in an xterm and it's necessary to set TERM=xterm,
> > but that's another issue (or at least I think it is).
>
> No, it's not another issue.
>
> Ian.
>
Reply to: