unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)
@ 2011-04-26 17:46 Brett Hoerner
  2011-04-26 18:59 ` Brett Hoerner
  0 siblings, 1 reply; 6+ messages in thread
From: Brett Hoerner @ 2011-04-26 17:46 UTC (permalink / raw)
  To: help-gnu-emacs

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.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)
  2011-04-26 17:46 shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select) Brett Hoerner
@ 2011-04-26 18:59 ` Brett Hoerner
  2011-04-27 16:20   ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Brett Hoerner @ 2011-04-26 18:59 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)
  2011-04-26 18:59 ` Brett Hoerner
@ 2011-04-27 16:20   ` Stefan Monnier
  2011-04-28  0:49     ` Brett Hoerner
  2011-05-01 14:44     ` Thomas E. Dickey
  0 siblings, 2 replies; 6+ messages in thread
From: Stefan Monnier @ 2011-04-27 16:20 UTC (permalink / raw)
  To: help-gnu-emacs

> 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)
  2011-04-27 16:20   ` Stefan Monnier
@ 2011-04-28  0:49     ` Brett Hoerner
  2011-05-01 14:44     ` Thomas E. Dickey
  1 sibling, 0 replies; 6+ messages in thread
From: Brett Hoerner @ 2011-04-28  0:49 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)
  2011-04-27 16:20   ` Stefan Monnier
  2011-04-28  0:49     ` Brett Hoerner
@ 2011-05-01 14:44     ` Thomas E. Dickey
  2011-05-02 14:04       ` Stefan Monnier
  1 sibling, 1 reply; 6+ messages in thread
From: Thomas E. Dickey @ 2011-05-01 14:44 UTC (permalink / raw)
  To: help-gnu-emacs

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select)
  2011-05-01 14:44     ` Thomas E. Dickey
@ 2011-05-02 14:04       ` Stefan Monnier
  0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2011-05-02 14:04 UTC (permalink / raw)
  To: help-gnu-emacs

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-05-02 14:04 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-26 17:46 shift+up received as <select>, breaking Emacs 24 "shift select" (like pc-select) Brett Hoerner
2011-04-26 18:59 ` Brett Hoerner
2011-04-27 16:20   ` Stefan Monnier
2011-04-28  0:49     ` Brett Hoerner
2011-05-01 14:44     ` Thomas E. Dickey
2011-05-02 14:04       ` Stefan Monnier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).