Change The Escape Sequence Generated by Xterm for Key Combinations

Change the escape sequence generated by xterm for key combinations

xterm can be configured to send custom strings when certain keys are pressed by modifying its translation table. The translation table is part of the X resource database managed by the xrdb command.

There's a good example of a customized translation table for xterm here. It can be copied into your $HOME/.Xdefaults or $HOME/.Xresources and it will be loaded the next time you log in. To load it into your current session immediately, xrdb -merge $HOME/.Xresources. This won't affect any xterms that are already running. (You might be able to change the translation table of a running xterm with editres, but that's more trouble than it's worth.)

To provide a custom translation table for a single instance of xterm, use the -xrm option, as in

xterm -xrm 'XTerm.VT100.translations: #override Ctrl<Key>Left: string(0x1b) string("b") \n Ctrl<Key>Right: string(0x1b) string("f")'

Change the escape sequence generated

There is no universal way to do this. Each terminal widget (VTE, etc.) has its own method for translating keypresses into character sequences, and some may even hardcode it in the code itself.

Trying to use xTerm to send command or control key combinations

Ok, just as I was posting this querstion, I found the answer.
I found it here: https://mw.lojban.org/papri/List_of_ASCII_letterals#ASCII_control_code_chart

under ASCII control code chart, under ^X which has the ASCII code of 18, which I send to xTermJs as \x18. This immediately solved my problem.

Seems like even these character combinations are defined as 1 ASCII character, and not 2 used together. In this case, my Control+X character is actually called a "Cancel" character.

xterm reports wrong escape sequences on raw input

Terminal descriptions' list of special keys are written with the assumption that an application has initialized the terminal for full-screen mode, using application mode for special keys rather than the initial normal mode. Command-line applications generally do not do this (they could, of course: look for smkx and rmkx).

what is terminal escape sequence for ctrl + arrow (left, right,...) in TERM=linux

Terminals were hardware devices that consisted of a keyboard and an output device (initially a hardcopy printer, later a CRT monitor). A large computer could have several remote terminals connected to it. Each terminal would have a protocol for communicating efficiently with the computer, for CRT-based terminals this includes having special "control sequences" to change cursor position, erase parts of the current line/screen, switch to an alternate full-screen mode, ...

A terminal emulator is an application emulating one of those older terminals. It allows to do functions like cursor positioning, setting foreground and background colors, ... Terminal emulators try to emulate some specific terminal protocol, but each has its own set of quirks and deviations.

Unix systems have databases describing terminals and terminal emulators, so applications are abstracted away from the particular terminal (or terminal emulator) in use. An older database is termcap(5), while terminfo(5) is a newer database. These databases allow applications to query for the capabilities of the terminal in use. Capabilities can be booleans, numeric capabilities, or even string capabilities, e.g.: if a specific terminal type has/supports a F12 key, it will have a capability "key_f12" (long terminfo name), "kf12" (short terminfo name), "F2" (termcap name) describing the string that key produces. Try it with: tput kf12 | od -tx1.

Since programming directly with capabilities can be cumbersome, applications typically use a higher-level library like curses/ncurses, slang, etc...

There is a special environment variable called TERM that tells applications what terminal type they are talking to. This variable should be set to the exact terminal type if it exists in the database, for best results. This just tells the application which precise protocol and protocol deviations does the terminal understand. Changing the TERM variable does not change the terminal type, it just changes the terminal type the application thinks it is talking to.

All that said, Ctrl+arrow is a xterm behaviour (dependent on a configuration option) that is not reflected at all in the terminfo/termcap databases, so most applications will have no knowledge of it. Either way, either your terminal emulator (in your case pyte) supports it or it doesn't.

Assuming your main application is bash or some other application that uses the readline library, you may get away with using readline's backward-word (Meta-b/Alt-b/ESC b by default, configurable in inputrc) instead.

Determine escape sequence independent from terminal type

If you're wanting to read terminal keypresses, you likely want to look at something like libtermkey , which abstracts the general problem away for you. Internally it uses a combination of terminfo lookups, or hardcoded knowledge of the extended xterm-like model for modified keypresses, so it can understand things like Ctrl-Up, which a regular curses/etc... cannot.

while((ret = termkey_waitkey(tk, &key)) != TERMKEY_RES_EOF) {
  termkey_strfkey(tk, buffer, sizeof buffer, &key, TERMKEY_FORMAT_VIM);
  printf("You pressed key %s\n", buffer);

  if(key.type == TERMKEY_TYPE_FUNCTION &&
     !key.modifiers &&
     key.code.number = 2)
    printf("Got F2\n");
}

Send C-( to Emacs in VT100/xterm terminal (Mac OS X's Terminal)?

A VT100 terminal couldn't do that, because there is no ^( control character corresponding to (. However, xterm has the so-called "modifyOtherKeys" mode, which does allow to send unique keycodes for combinations like that.

To enable it, set the modifyOtherKeys resource, e.g. in ~/.Xdefaults:

XTerm*vt100.modifyOtherKeys: 1

With that, Ctrl+( will send the following keycode:

^[[27;6;40~

That's rather long though, so another format for keycodes like that was introduced, which can be enabled by setting the formatOtherKeys resource:

XTerm*vt100.formatOtherKeys: 1

With that, Ctrl+( sends:

^[[40;6u

In both of these keycodes, the 40 is the decimal ASCII code for (, and the 6 represents the Ctrl.

See man xterm and http://invisible-island.net/xterm/ctlseqs/ctlseqs.html for further details. No idea whether Terminal.app supports any of it.

How do I find out what escape sequence my terminal needs to send?

XTerm

Since you are advertising that you are using an xterm (via your TERM value), you will most likely want to arrange to send the sequences that xterm would send for these keys. The ctlseqs documentation from xterm describes these particular modified key sequences at the bottom of the PC-Style Function Keys section:

… xterm recognizes function key modifiers which are parameters appended before the final character of the control sequence.
    2 Shift
    3 Alt
    4 Shift + Alt
    5 Control
    6 Control + Shift
    ⋮

Examples

F5 sends ^[[15~, so Shift-F5 should send ^[[15;2~ (i.e. add ;2 before the final character)

The arrow keys and the first four function keys are a bit different. They often use SS3-based sequences (starting with ^[O); these will need to be changed to CSI-based equivalents (starting with ^[[) since SS3 sequences can not have parameters. Also, the normal sequences for the keys do not usually have a numeric parameter, so a placeholder(?) 1 parameter is also added:

Up sends ^[[A or ^[OA, so Shift+Up should send ^[[1;2A (i.e. switch to CSI, and add 1;2 before the final character)

F1 sends ^[OP, so Shift+F1 should send ^[[1;2P (i.e. switch to CSI, add 1;2 before the final character)

You might also like to look at the source code of various terminal emulators to see whay they do. For example, the relevant bits of tmux are in its xterm-keys.c file.

Configuration

Since your terminal emulator is not already sending all the sequences you want to support, you will have to configure it to do so. The built-in terminal emulator that comes with OS X, Terminal, has a few keys preconfigured, but you will probably have to add most of them yourself. You can get to the list of keys by invoking the Terminal > Preferences… menu item, selecting the top-level Settings tab, picking the appropriate profile, and switching to its Keyboard tab. From there you can add and remove key definitions. For example, you could define F2 with shift to send string to shell: (sic) and type ESC followed by [1;2Q into the string text box (the ESC will show up as \033, this is okay).

Note: Changing the definition of Option-Right and Option-Left might affect how some programs (e.g. shells and Emacs) work with those keystrokes. The default configuration sends ESC-f and ESC-b, which are Emacs-style keystrokes for backward-word and forward-word that many programs will understand by default. This configuration seems backwards to me; the shell (and other programs) should be configured to recognize proper modified arrow key sequences instead.

You might also want to try a different terminal emulator. iTerm 2 has built-in support for most of these modified keys (maybe not the Control+Fn variants), so there would be less to manually configure.

Also, note that OS X has some system-wide shortcuts defined for some of the Control-Fx combinations (see System Preferences, Keyboard, Keyboard Shortcuts, Keyboard & Text Input). You will have to disable some of these shortcuts to make sure that Terminal or iTerm has a chance to “see” your desired key combinations.