1

I am using org-mode in emacs in the terminal and the Shift and Alt cursor combinations are entered as characters like 2A, 2B, 3A etc. I notice that vim and the terminal also display such behaviour.

Are there some terminal settings that can be set to change this behaviour, or is it settings in emacs and vim themselves?

Following up on Gilles advice:

The terminal emulator is KDE Konsole. On account of some advice given I went into the Settings->Configure Shortcuts menu and disabled the use of Shift+Left and Shift+Right for the Previous Tab and Next Tab options.

Emacs

Shift+Left -> ^[2D

Shift+Right -> ^[2D

Alt+Left -> ^[3D

Alt+Right -> ^[3C

Vim 

Shift+Left -> ^[[1;2D

Shift+Right -> ^[[1;2C

Alt+Left -> ^[[1;3D

Alt+Right -> ^[[1;3C
|improve this question
  • Press Ctrl+V then Shift+Left in Vim insert mode, or Ctrl+Q then Shift+Left in Emacs. What is inserted? Same question with Alt+Left. What terminal emulator are you using, on what distribution? – Gilles Jul 6 '17 at 23:42
  • The only terminal-relevant setting would be the environment-variable TERM, which we're assuming is "xterm". That won't change what konsole sends, but affects the applications running in konsole. – Thomas Dickey Jul 9 '17 at 15:49
1

It's settings in the applications themselves, combined with the terminal.

The DEC VT behaviour, that is being imitated by Xterm, sends an extended key event as a control sequence with parameters. A lot of naïve programs cannot decode these properly, as they wrongly expect keyboard control sequences to be simple control sequences without parameters. Some of them are so naïve that they do not even look for intermediate and final characters properly. They end up decoding only part of the control sequence and treating the rest as ordinary input, resulting in oddities such as what you are seeing.

vim is capable of decoding such keyboard sequences properly, and how you ensure that it does is explained in the xterm-modifier-keys section of its on-line help.

nvim is, too, although it does not require that one set up termcap variables in the way that one does for vim.

The twist is that applications like this also require that the terminal think that it is in application cursor key mode and application keypad mode. Usually, terminals are in normal cursor key mode and normal keypad mode. These applications tell the terminal to switch modes, for the duration, by printing out a control sequence to the terminal.

|improve this answer
  • Emacs has no problem coping with escape sequences either. Both Vim and Emacs may need to be configured to cope with certain escape sequences. – Gilles Jul 6 '17 at 23:41
  • application-mode isn't relevant here. – Thomas Dickey Jul 9 '17 at 15:28
  • Yes, it is, for the reason stated. This is something that I had to fix in nvim as a matter of fact. – JdeBP Jul 9 '17 at 15:50
1

The terminal description (supposing that your TERM is set to "xterm") supplies the information necessary (see for example the comment before the xterm+pcfkeys entry).

xterm since 1999 (and its imitators konsole and gnome-terminal, starting a few years later -- see the xterm FAQ) provide an extended set of function-keys using shift-, control-, alt- and meta-modifiers:

add parameters to function keys to indicate if shift, control or alt are set. The codes are based on a description of a DEC VT510 with a PC keyboard

Whether xterm is "imitating" a DEC VT is of course debatable: at the time, there was no freely-available manual, so the "description" was via email in a few lines of text. Expect some variation.

The initial behavior was altered in 2002, making xterm send a number as the second parameter to tell which modifiers are used (after the "1" which emacs may interpret as a repeat-count).

The followup with examples for vim and emacs citing konsole is interesting:

  • Both are termcap applications, which means that (although the details have been supplied in the terminfo description for more than 10 years, neither of those programs actually uses the terminal description, because the names by which those capabilities are referenced are not (and likely never will be) found in a termcap file.
  • Both programs have some workaround, e.g., vim's documentation for xterm-shifted-keys, xterm-modifier-keys, xterm-codes. For emacs, the documentation is not as concise (the discussion of keymaps for instance), but it helps to read the source-code, e.g., lisp/term/xterm.el
  • The interesting part is that what emacs echoes is different from what vim echoes, and that the former resembles the older/obsolete behavior. Not only is it obsolete, but konsole and gnome-terminal developers having copied it, did not bother to follow xterm's change for more than ten years (giving rise to numerous bug-reports). emacs' workaround may be a result of that.
|improve this answer
1

After following Gilles's advice in his comment on the question and some more web searches I came across this link https://github.com/bendikro/emacs-conf/blob/master/emacs-conf/key-bindings.el with some sections define the keys appropriately. 

;; ;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ;; Fix for screen / tmux
;; some snipped code

;; Fix ALT + arrow keys inside screen/tmux
(define-key input-decode-map "\e[1;3A" [M-up])
(define-key input-decode-map "\e[1;3B" [M-down])
(define-key input-decode-map "\e[1;3C" [M-right])
(define-key input-decode-map "\e[1;3D" [M-left])

I copied and adapted it for Shift as well and it seems to be working okay now.

|improve this answer
  • Before trying this with tmux, try tmux setw -g xterm-keys! – user1338062 May 17 '18 at 3:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.