Request: Make alt-arrow escape sequences default on OS X version of iTerm 2

Every time I reinstall, I have to look up these escape sequence codes. Since they are stock behavior in most terminals (including the OS X Terminal.app), shouldn't they be included by default now?

I hadn't noticed that Terminal changed its default behavior. I'm glad it did because the new defaults make more sense.

What you want is available as a preset, though. Select "Natural text editing" under Prefs>profiles>keys>Load preset….

Milestone changed to Feature Complete 3.1

Thanks! I think the confusion is regarding the 2.1.1 stable release vs the beta. I was using the standard one. I grabbed the beta and now I see this preset.

I appreciate the help.

mentioned in issue #3755 (closed)

What is the default behavior of the alt-arrow key combinations in iTerm2?

It looks like it's ^[[1;9A, ^[[1;9B, ^[[1;9C, ^[[1;9D for Alt-up, -down, -right, and -left respectively, and that they are not sensitive to the xterm smkx/rmkx "application keypad" sequence (^[[?1h^[=). Is that right, and is this documented somewhere? Where did these sequences come from?

Application keypad mode (^[=) and application cursor mode (^[[?1h) are both respected. The pseudocode for left-arrow key is like this:

if (in application keypad mode) {
  send escape sequence from terminfo (`^[OD` for left arrow if your terminal is xterm)
} else {
  if (modifier keys are pressed) {
    send escape sequence with modifiers and key code as separate parameters ( `^[1b[1;9D` for alt-left arrow)
  } else if (application cursor mode) {
    send escape sequence for cursor mode (`^[OD` for left arrow; this happens to be the same as the terminfo sequence for xterm)
  } else {
    send escape sequence for regular mode (`^[[D` for left arrow)
  }
}

The goal is to do the same thing as xterm, which we may or may not achieve in all cases because this code is really old and not very good and I want to rewrite it. If you find a bug please let me know.

Thanks for the explanation.

I'm seeing a couple behavior differences here with respect to xterm.

The first is that the modifiers used in the case of Alt are different. I'm seeing xterm and iTerm2 send the following for Alt- up, down, left, and right arrows, respectively.

xterm: ^[[1;3A ^[[1;3B ^[[1;3C ^[[1;3D

iterm2: ^[[1;9A ^[[1;9B ^[[1;9C ^[[1;9D

I tested that with xterm 314 on OS X 10.9.5 (using xterm from XQuartz 2.7.8) and xterm 312 on Debian Linux 8, and no customizations to X resources.

I think what's happening is that xterm is reporting the modifier as Alt, but iTerm2 is reporting it as Meta. That's based on the list of modifier codes in the xterm Control Sequences document here.

                    Code     Modifiers
                  ---------+---------------------------
                     2     | Shift
                     3     | Alt
                     ...
                     9     | Meta
                     10    | Meta + Shift
                     11    | Meta + Alt
                     ...

It seems like iTerm should be using Alt, too, at least if the "Left/right option key acts as:" setting in the profile is "Normal" instead of "Meta" or "+Esc".

The other difference is with respect to the application modes and the pseudocode you described. In xterm, that same ^[[1;3A style sequence is sent for Alt-arrow, regardless of whether application keypad or application cursor modes are set. And the application keypad mode never affects the output of the cursor keys. But my tested behavior for iTerm 2.1.4 matches xterm's for the modifier keys taking precedence over keypad/cursor modes. (I put my observations for xterm in this Google spreadsheet.)

Thanks for digging into this, @apjanke. I plan to do a rewrite of how keyboard input is processed in version 3.1.

alt vs meta: I can't recall how we ended up with meta instead of alt. Based on your spreadsheet we should be sending 3, though.

I'll make sure to revisit how application keypad mode and application cursor mode are handled during the rewrite. That spreadsheet will be very useful as a starting point.

Milestone changed to Feature Complete 3.2