Add support for modifier key resources

[CaptainOnly]

This set of commits ostensibly adds support for the modifier key resource values accessed via the "CSI > Ps; Ps m" sequences. I tried to make it easy to support other use cases, but I have added support specifically for using emacs as the application and mintty as the user terminal. This requires carrying some terminal type/version information from the user side to the application side so that emacs can detect when the resources are available automatically.

[cgull]

Hi Erik, thanks for opening this PR!

The code itself looks plausible, but the thing I'm currently trying to figure out is its use case, and how generally applicable it is. If I'm understanding this correctly, you coded this up because control-backspace doesn't work for you in Emacs with Cygwin & mintty, and this fixes it. Have I got that right?

Things that concern me a bit about the code:

• It only supports mintty (and maybe some specific ancient obscure version of XTerm).
• It adds a little ad-hoc parser for the CSI SDA response from the terminal.
• More importantly, it provides a different, varying CSI SDA response to host applications. I haven't dug into it, but I suspect the response you've chosen implies not just support for modifier key resource values, but a host of other obscure XTerm capabilities. I suspect very few applications use CSI SDA to determine terminal capabilities like Emacs does-- but Mosh's VT220/XTerm emulation is already rather incomplete, and I'd rather not have it say it supports an even larger range of missing features. Also, right now, any single Mosh version provides a single unchanging set of virtual terminal capabilities, no matter what the client terminal is. This changes that (very slightly).

Things I see when looking at this:

• With my fairly-vanilla Emacs 26.1 install and mintty 2.9.0, Emacs does seem to enable modifier key resource values, but does not install a handler/binding for that CSI sequence, so I get some ANSIbake in my emacs buffer rather than anything useful. (Outside of Emacs, control-backspace sends the rather-unusual ^_).
• I use console-mode Emacs a fair bit, but I've never noticed this problem, since I use Alt-backspace to delete backwards by word. In X11 Emacs, the bindings are: C-backspace -> backward-kill-word, and M-backspace -> M-DEL -> backward-kill-word.
• All the other terminal emulators I have handy (gnome-terminal, Konsole, xterm, putty) do something more reasonable with control-backspace, sending either DEL or ESC DEL. They all send ESC DEL for alt-backspace. Also, Emacs doesn't seem to enable modifier key resource values, at least not for the backspace key.

So my thinking is that this change has a quite narrow use case, to fix something that is arguably an incompatibility/bug in mintty. An alternate solution to this problem would be to change mintty: maybe just eliminate its use of ^_, or add a configuration option in mintty to have it always send DEL/ESC DEL, instead of ever using ^_-- that's a simpler fix and more broadly applicable. I keep an eye on Cygwin, and the mintty developer seems responsive, and is actively working on it right now.

But I don't think I completely understand your issue, if I'm missing something let me know and we'll work to a better solution.

[CaptainOnly]

Hey cgull,

Thanks for the through response, and thanks for working on mosh!

I agree that this is pretty specific to the emacs-in-mintty case. I only intended it as a proof of concept, so I don't expect it to be accepted. I happen to be using this personally and I'm happy with that.

Regarding the "ANSIbake": Yeah I have to add a keybinding in emacs for that sequence. At least with these patches I get a sequence specific to control-backspace. This means that mintty's ^_ and it's modifier key equivalent are both unusual. I'll try to follow up with them to understand why.

You are right that the CSI SDA response implies all kinds of features. In fact, this change also allows clipboard integration to work which is really nice! I'd be interested in helping to fill out that xterm emulation more if it becomes a priority at some point, whether this turns out to be the way to do it or not.

I've not done this before. Should I close the request?

[huyz]

My use case for this is as follows:

I use (neo)vim inside of tmux inside of mosh inside of iTerm2. But I think the use case is the same even if we take tmux out of the equation: (neo)vim inside of mosh inside of iTerm2.

First thing to know is that iTerm2 supports "xterm control sequence can enable modifyOtherKeys mode". So vim can toggle that mode with the proper:

        let &t_TI = "\e[>4;2m"
        let &t_TE = "\e[>4;m"

This lets me use <C-S-n> key sequences, e.g. <C-S-R> and <C-S-BS>. This would require the terminal client to support modifyOtherKeys=2.

Specifically for tmux, but perhaps irrelevant to this PR, tmux only understands modifyOtherKeys=1. However, if I understand tmux/tmux#3086 (comment) correctly, tmux has partially implemented some key sequences of modifyOtherKeys=2. But the problem is that when I run neovim inside tmux inside mosh inside iTerm2, iTerm2 does not automatically change the terminal state to modifyOtherKeys Mode 2 from Standard Key Reporting Mode.
The workaround is to manually change this session's terminal state to modifyOtherKeys Mode 2 and my key sequences work. Not all will work (<C-i> will still be indistinguishable from <Tab>) but plenty of keys do work, including <C-S-R>.

Manual intervention is inconvenient so I would like to let vim toggle iTerm2's modifyOtherKeys state. For that to happen, mosh has to let it pass through.

Could mosh have some sort of escape valve to allow escape sequences to pass through to the client terminal? tmux 3.3 has added such an escape valve using an allow-passthrough option: https://github.com/tmux/tmux/wiki/FAQ#what-is-the-passthrough-escape-sequence-and-how-do-i-use-it

Perhaps mosh can support something similar: a special passthrough escape sequence.

As a user, this would still not be easy as I'd need to double escape the sequence, once for tmux and once for mosh, depending of they're detected from within my vim config files. I may have to use something like this to detect a mosh session: https://unix.stackexchange.com/a/396888/7281
(Or perhaps, I'll send both regular and mosh-passthrough sequences.)

Other ideas welcome.