[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shift+up received as <select>, breaking Emacs 24 "shift select" (lik
From: |
Thomas E. Dickey |
Subject: |
Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select) |
Date: |
Tue, 24 May 2011 20:01:40 -0000 |
User-agent: |
G2/1.0 |
On Apr 27, 12:20 pm, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> > For what it's worth, <shift>+<up> is <select> in Emacs 23, too.
>
> Indeed, it's the case at least since Emacs-20. Do the following:
>
> a a a a a <shift>+<up> C-h l
>
> You'll see that the events received from the terminal were: a a a a
> a ESC [ 1 ; 2 A C-h l and hence Emacs translated ESC [ 1 ; 2 A to <select>.
> Now the question is why did Emacs translated ESC [ 1 ; 2 A to <select>
> rather than to S-<up>. lisp/term/xterm.el says:
>
> (define-key map "\e[1;2A" [S-up])
>
> so Emacs's own data seems correct. But this data is overridden by the
> data provided by the terminfo database, so my guess is that the terminfo
> database is incorrect (and/or that the byte sequences sent by those
> terminal emulators for S-up and select are the same, so the database is
> not incorrect, but the result is still undesirable).
Third possibility overlooked: gnome-terminal uses a deprecated form of
the control sequences, so what it sends won't match what xterm does.
ncurses has a correct terminal description for "gnome", however it's
not
useful for two reasons:
(a) gnome-terminal sets $TERM to "xterm", and
(b) gnome-terminal's termcap-specific logic doesn't handle the
terminfo extensions such as this one.
vte's hackers have dithered about this for eight years without
releasing a workable solution.