better function key support for rxvt-unicode

[matthias314]

This PR (copied here from zyedidia#30) adds function key support for rxvt-unicode (urxvt) in a way analogous to xterm. Specifically, it can report the following keys:

• F1 to F10, also with any combination of Shift, Ctrl and Alt. (Alt plus function key is often caught by the window manager, however.) Currently combinations of function keys with Shift are reported as F11 to F20 and the rest as raw key events.
• F11 and F12 (and up to F20, if you have them) if used together with Shift and possibly Ctrl and/or Alt.
• Insert, Delete, Home, End, PageUp, PageDown, also with any combination of Shift, Ctrl and Alt (Note that by default Shift plus Insert, PageUp and PageDown are caught by urxvt for its own purposes.) Currently, the modifier combinations Shift+Ctrl and Alt-Shift-Ctrl are reported as raw key events.
• Up, Down, Right, Left, also with Shift or Ctrl, possibly plus Alt. Currently Ctrl-Up is reported as raw key event (same plus Alt) and Ctrl-Shift-Up as Up (same plus Alt) .

The following work with tweaking the user's .Xresources:

• By default, urxvt doesn't distinguish F11 (plus Ctrl) from Shift-F1 (plus Ctrl), same for F12 (up to F20). I've added newly invented key codes for these cases. To use them, one needs to add something like the following to .Xresources:

  URxvt.keysym.F11: string:\033[23#
  URxvt.keysym.S-F11: string:\033[23$
  URxvt.keysym.C-F11: string:\033[23&
  URxvt.keysym.C-S-F11: string:\033[23@
  URxvt.keysym.M-F11: string:\033\033[23#
  URxvt.keysym.M-S-F11: string:\033\033[23$
  URxvt.keysym.M-C-F11: string:\033\033[23&
  URxvt.keysym.M-C-S-F11: string:\033\033[23@
  

  Then F11 works with any combination of modifiers. For F12 one needs to replace [23 by [24.
• urxvt sends the same key codes for Shift-Up and Ctrl-Shift-Up, and similarly for the other cursor keys. I've instead implemented the "application mode" codes for Ctrl-Shift, see the urxvt documentation. To use them, one needs something like the following in .Xresources:

  URxvt.keysym.C-S-Up: string:\033OA
  URxvt.keysym.C-S-Down: string:\033OB
  URxvt.keysym.C-S-Right: string:\033OC
  URxvt.keysym.C-S-Left: string:\033OD
  URxvt.keysym.M-C-S-Up: string:\033\033OA
  URxvt.keysym.M-C-S-Down: string:\033\033OB
  URxvt.keysym.M-C-S-Right: string:\033\033OC
  URxvt.keysym.M-C-S-Left: string:\033\033OD
  

  Then cursor keys work with any combination of modifiers. (Some might be caught by the window manager.)

The PR also seems to work with rxvt-like terminals (tested with Eterm). I don't kow about the original rxvt; I didn't find it in a web search.

[JoeKar]

Please also consider checking gdamore/tcell, since this might be upstream relevant and then should be fixed there too.

[matthias314]

@gdamore Would you be interested in this PR? It has several merge conflicts with your main branch, so I'd rather ask before I start fixing them.

[matthias314]

It seems that @gdamore is not interested. Are you, @JoeKar?

[JoeKar]

Maybe he prefers to receive it as issue or PR directly within the upstream repository.

I've no problem with such stuff, but we've to keep in mind that we like to get closer to the upstream version instead of moving away. 😉
When we go such a direction we might end in a situation of allowing special modified treatment for all the different terminals. 🤔

Anyway please leave it open till we find some time to consider it.
Currently we're really busy with the tons of issues and PRs opened in micro itself.

[gdamore]

In general I don't necessarily see issues you mention me on, as I don't look for mentions. I do monitor against my own repos of course, but this was filed against a downstream fork.

Now I've made a bunch of changes recently to tcell that probably works well with rxvt.

Having said that, my local urxvt (which I'm not a frequent user of) uses Shift and Control with function keys to access higher numbered function keys, rather than modified function keys.

I'll also note that urxvt seems to be lagging in that it does not support any of the nicer and newer key protocols -- there are three possible choices it could use, and we'd work better if it supported any of them. In decreasing order of priority:

• win32-input-mode (dec private mode 9001, uses CSI - _ to send full protocol keys)
• kitty protocol (aka CSI-u mode) - this is the most popular one for modern terminal emulators
• xterm modify-other-keys protocol (this sends escape sequences for modified keys using a simple protocol)

I don't love the idea of hard coding escape sequences that only work with hand-tuned Xresources.

In fact, if you're going to do that, with new tcell, you could instead make those resources just send escape sequences that match one of the ones we already support. (Tcell v2.10 and higher will now decode all the key sequences, so if it matches any of them it will match all of them.)

At that point you can just make these send the kitty/xterm sequences instead. For example:

Shift Control F1 (F1 uses CSI final byte A):

\x1b [  1 ; 6 A 

That is, it is CSI 1 ; 6 A

The value for 6 can be calculated as a bit mask + 1 ...

The following modifiers are known:

Shift - 1
Alt - 2
Control - 4
Meta - 8

(There are others as well).
Add those together and add one for the modifier value (e.g. (1 + 4) + 1 = 6

The base key is the final letter in the sequence. Here are the known values:

	'A': KeyUp,
	'B': KeyDown,
	'C': KeyRight,
	'D': KeyLeft,
	'F': KeyEnd,
	'H': KeyHome,
	'P': KeyF1,
	'Q': KeyF2,
	'R': KeyF3,
	'S': KeyF4,
	't': KeyF5,
	'u': KeyF6,
	'v': KeyF7,
	'l': KeyF8,
	'w': KeyF9,
	'x': KeyF10,

So you could simply change your Xresources to match the existing protocol, instead of inventing something new.

[gdamore]

Upstream tcell won't recognize your newly invented escape sequences, given that a reasonable solution (outlined above) already exists.