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