shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)

shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)

[Brett Hoerner]

If I start Emacs 24 with emacs -nw -Q in any (default configured) terminal editor like gnome-terminal or Terminal.app, shift+up is received as "<select>".

In other words,

C-h k <shift>+<right> = right-char
C-h k <up> = previous-line
C-h k <shift>+<up> = <select> is undefined

The problem is that shift+left,right,down all select/mark text in that direction in Emacs 24, but shift+up does nothing. Now, I'm further confused by how "shift" comes into play, since those are all bound to things like "right-char" not something like "mark-right-char". So when I go ahead and make a binding like,

(define-key global-map (kbd "<select>") 'previous-line)

It makes <shift>+<up> work as previous-line, but it doesn't select/mark the text like <shift>+left,right,down magically seem to.

I think I have two separate issues (or confusions) here. Any help is greatly appreciated.

Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)

[Brett Hoerner]

For what it's worth, <shift>+<up> is <select> in Emacs 23, too. This isn't a 24 issue, the only difference is that 24 defaults to shift+direction = select, which seems broken for "up".

Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)

[Stefan Monnier]

> 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).

You should be able to work around the issue with something like:

  (define-key input-decode-map "\e[1;2A" [S-up])

And for this to take effect at the right time, you will have to use in
your .emacs something like:

  (if (equal "xterm" (tty-type))
      (define-key input-decode-map "\e[1;2A" [S-up]))

and if you use Emacs with multiple terminals, you'll additionally need:

  (defadvice terminal-init-xterm (after select-shift-up activate)
    (define-key input-decode-map "\e[1;2A" [S-up]))

This is a bit cumbersome, so feel free to file a bug-report about it.

> This isn't a 24 issue, the only difference is that 24 defaults to
> shift+direction = select, which seems broken for "up".

It's not broken for "up", it's just that Emacs thinks you've just hit
<select> and hence doesn't realize you've used a shifted key.


        Stefan

Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)

[Brett Hoerner]

That all worked perfectly and made sense, thank you so much.

Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)

[Thomas E. Dickey]

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.

Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)

[Stefan Monnier]

>> 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.

I can reproduce the OP's problem in Debian's `xterm' (I never like the
new terminals with menubars and stuff), so it's not specific to
gnome-terminal.


        Stefan