New extended xterm key presets

[choppsv1]

Add another preset for profiles that maps all the xterm codes I could find (used emacs xterm.el source actually for discovery). Additionally filled in where there were gaps and an obvious pattern (e.g., xterm doesn't define X-2 through X-8 where X is any combination of modifiers.

This creates mappings for all US keys on a laptop for all combinations of control, shift and option (alt). The sequences sent are alt and not meta based (which is what, for example, tmux translates meta to anyway).

[gnachman]

This looks great, thanks for putting it together! Any reason you chose to create a new preset instead of extending the existing "xterm Defaults" preset?

[choppsv1]

So my thinking was since I did extend it a little bit (e.g., adding C-2 -> C-8) I wasn't being completely true to what xterm supported (I don't know why it doesn't suppose those in particular), I should create it's own setting.

[choppsv1]

actually your question got me thinking what exactly did I change. Originally I started this as just a way to generate some sequences that I could then program emacs to interpret as those keys, but then decided why not use what was there from xterm. If we really want to call this Xterm++ it should probably be as close as possible for all the supported keys. So I reviewed my change in that light. It seems that for meta and meta-shift, all keys are supported simply by their being able to be sent prefixed by the escape character. So I should remove any special handling for those.

I'll update my branch/PR.

[gnachman]

Is this based on how function keys are treated as described in the last section of PC-Style Function Keys section of http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-PC-Style-Function-Keys ?

I want to be really clear on what this key mapping does. It looks like it goes beyond what xterm does (or is there some configuration flag that gives it this behavior?). For example, why does ctrl-shift-A send CSI 27;8;65~? The 27 seems to get used a lot but I can't tell where it comes from. 8 and 65 are obviously the modifier and ASCII code, but their order is reversed versus xterm's PC-style function keys, where the modifier goes last.

If this is really a new invention (versus a tweak to xterm's existing scheme), how does it compare to libtermkey described here: http://www.leonerd.org.uk/hacks/fixterms/

Thanks for the clarification! It's important to get this right because the standards here are pretty crazy and hard to understand.

[choppsv1]

You are correct many keys use the "CSI 27;mod;decchar~" sequence. I think perhaps source is simpler in this case, so here's the python I used to generate the data:

https://gist.github.com/8af4d179794c2603362e

You can see the behavior in xterm by setting modifuOtherKeys option (see http://invisible-island.net/xterm/manpage/xterm.html) and playing around in cat. I originally gleamed on to this by looking at emacs xterm.el .

This looks similar to what's being done with libtermkey (the modifiers appear to use the same ascii decimal values for shift and ctrl), but obviously there's some difference.

Actually if you check out the comment from Giles on http://emacs.stackexchange.com/questions/1020/problems-with-keybindings-when-using-terminal he mentions both efforts. I didn't realize that emacs actually enables the xterm setting modifyOtherKeys option!

[choppsv1]

I was looking over my control-key exceptions in the python code and realized I missed one keyboard ascii key: space!

I'll update the branch with this key (and of course leave C-space as ^@ which is what I was originally looking for :)

[gnachman]

Good to have a name for this! We should call it "xterm modifyOtherKeys mode". What happens with non-US keyboards? Is there a general algorithm? I wonder if this should not be a preset, but if it should be implemented in code to handle these cases.

[orb]

I copied this into my iTerm and set the terminal type to xterm. This is pretty amazing, but I'm seeing several key sequences that don't work as expected. Many of the [27;n;n~ sequences are not recognized.

For example, C-_ sends [27;6;95~ but there's nothing in xterm.el that seems to respond to that.

Another one that doesn't work is M-S-right. This is sending [1;4C, and xterm.el has (define-key map "\e[1;4C" [M-S-right]). Everything seems in order, but it doesn't work.

[DarMontou]

@orb, it looks like @choppsv1 has a custom/extended version of xterm.el with extra bindings for things like C-_

I was having the same trouble with M-S-right resolving to M-right. I tried the same command in windows emacs and noticed a helpful message when checking the keybinding, translated from M-S-right. Which I'm guessing means that emacs truncated the command to a shorter one that is defined rather than the longer one that isn't defined. So I added the following binding and it worked as expected:

(global-set-key (kbd "M-S-<right>")
  '(lambda ()
    (interactive)
    (message "M-S-right!")))

[choppsv1]

I think George is correct here, rather than presets iTerm should instead do this in code. There are 2 methods:

modifyOtherKeys == 1 [implied formatOtherKeys == 0] # xterm patch 214
modifyOtherKeys == 1 formatOtherKeys == 1 # xterm patch 235

The latter method is a bit nicer since it's a shorter sequence, but it is newer as well.

214 method: CSI 27 ; <modifier> ; <ascii> ~
235 method: CSI <ascii> ; <modifier> u

I think iTerm should support both methods with preference settings to enable them.

Here's where you can find the xterm changes by patch. For some reason the files are double gzipped. http://invisible-mirror.net/archives/xterm/patches/

[gnachman]

I opened an issue to track this:

https://gitlab.com/gnachman/iterm2/issues/5377