search

ASHISH031192 / mintty

Automatically exported from code.google.com/p/mintty
0 stars 0 forks source link

Support xterm VT220-style function keys #213

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I use PuTTy in an environment where I need to use the "Xterm R6" option in the 
PuTTy >> Terminal >> Keyboard >> "Function keys and keypad" section. (FWIW, 
that keyboard mapping allows using the numpad keys to represent other logical 
keys, e.g. PF1-PF4; see also "http://www.columbia.edu/kermit/k95vtfk.html".) I 
don't see any equivalent option in the Mintty options dialog.

Would it at all be complicated/difficult to support those different 
terminal-types for the "function keys and keypad" option?

My hope that is if Mintty is indeed based largely on the PuTTy source-code, 
that the latent functionality is still all there in the source-code but that 
it's just a matter of presenting a UI for the functionality.

Original issue reported on code.google.com by tonyduck...@gmail.com on 20 Aug 2010 at 2:31

GoogleCodeExporter commented 8 years ago 
Keyboard handling is one of the few bits I redid from scratch, implementing 
xterm's keycodes with "PC-style" function keys 
(http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#PC-Style%20Function%20Ke
ys) and support for encoding modifier keys allowing combinations like 
Ctrl+Arrow. So no, the support for sending different keycodes is no longer 
there.

PuTTY's function key codes in xterm R6 mode largely do match mintty's anyway 
though. In particular, F1 through F4 send the DEC VT100's keycodes for PF1 
through PF4 in both. So is there anything that isn't working as expected?

Original comment by andy.koppe on 20 Aug 2010 at 4:30

GoogleCodeExporter commented 8 years ago 
In particular I'm looking for some of the VT220 (or maybe VT400?) specific 
key-mappings 
(http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#VT220-Style%20Function%2
0Keys), e.g. F13-F20 and the "application" mode numpad keys.

After reading-up further and finding the keycodes for those VT220 keys, I 
realized I could just use AutoHotKey (http://www.autohotkey.com/) to remap 
those keys and send the text I needed...which is what I just whipped-up and 
which seems to work great for me as a workaround.

It still might be worth considering adding native (opt-in) functionality in 
Mintty for those VT220 keycodes.

---

For reference, here's the AutoHotKey code I ended-up with:

#IfWinActive, ahk_class mintty  ;start mintty-specific commands
; Ensure Numlock always stays on, so that VT200 numpad mappings below work 
correctly.
; Note: this seems to force NumLock to always stay on across all applications...
SetNumLockState , AlwaysOn
; Add VT220-style keymaps, e.g. F13-F20 and  "application" mode numpad
; 
(http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#VT220-Style%20Function%2
0Keys)
; (http://www.cs.utk.edu/~shuford/terminal/vt100_numeric_keypad.txt)
; Note: SS3 = Esc+O, CSI = Esc+[
NumLock::SendInput {Esc}OP
NumpadDiv::SendInput {Esc}OQ
NumpadMult::SendInput {Esc}OR
NumpadSub::SendInput {Esc}OS
Numpad0::SendInput {Esc}Op
Numpad1::SendInput {Esc}Oq
Numpad2::SendInput {Esc}Or
Numpad3::SendInput {Esc}Os
Numpad4::SendInput {Esc}Ot
Numpad5::SendInput {Esc}Ou
Numpad6::SendInput {Esc}Ov
Numpad7::SendInput {Esc}Ow
Numpad8::SendInput {Esc}Ox
Numpad9::SendInput {Esc}Oy
+F3::SendInput {Esc}[25~
+F4::SendInput {Esc}[26~
+F5::SendInput {Esc}[28~
+F6::SendInput {Esc}[29~
+F7::SendInput {Esc}[31~
+F8::SendInput {Esc}[32~
+F9::SendInput {Esc}[33~
+F10::SendInput {Esc}[34~
#IfWinActive

Original comment by tonyduck...@gmail.com on 20 Aug 2010 at 6:24

GoogleCodeExporter commented 8 years ago 
Thanks very much for those details, and I'm glad you found a workable solution 
already. Right, let's tackle the three groups there separately.

PF1 to PF4:
F1 through F4 already send the PF1 to PF4 codes, i.e. '\eOP' to '\eOS'. 
Furthermore, numpad *, - and / each have their own application keypad codes: 
'\eOj', '\eOm', '\eO'. And even though NumLock, *, -, and / are in similar 
positions as PF1 to PF4, that mapping isn't exactly intuitive, even less so on 
laptop keyboards. So I'm not going to implement that.

Application keypad codes:
With xterm's PC-style keycodes, and NumLock off, the number keys on the keypad 
normally send the same codes as the cursor keys and the editing keys in the 
block of six above them. In mintty, you can get them to send VT220 application 
keycodes anyway, by enabling application keypad mode (with the DECPAM control 
sequence) while leaving the cursor keys in normal mode (controlled by the 
DECCKM sequence). Applications usually enable both application keypad mode and 
application cursor key mode though.

F13..F20:
These are actually supported, via the Windows virtual keycodes VK_F13 all the 
way up to VK_F24. Trouble is of course, you're very unlikely to find a PC 
keyboard that has all those keys. Apparently some Apple keyboards have function 
keys up to F16, and they might well work with Windows. Anyway, what this means 
is that it should be possible to map the function keys slight more 
straightforwardly in AutoHotkey, with mappings like '+F3::F13'.

However, the latter two answers are rather unsatisfactory, and xterm's 
VT220-style function key mode is something that mintty ought to support for the 
sake of compatibility. I probably wouldn't add a config dialog option for this, 
but just the '\e[?1061h' and '\e?1061l' control sequences for enabling and 
disabling VT220 mode.

You haven't really said though why VT220 mode is needed. I think most systems 
and applications these days take TERM=xterm to mean xterm in its default 
configuration with PC-style function and keypad keys.

Original comment by andy.koppe on 21 Aug 2010 at 11:40

GoogleCodeExporter commented 8 years ago 
Re: background, I'm dealing with a work environment where we have our own 
home-grown screen-entry code built on-top-of/into a database system. Our 
home-grown code is hard-coded to expect the VT220-style sequences and isn't 
influenced by the OS/shell $TERM value at all. It's code that was largely 
written 20+ years ago back when folks were (actually) using VT220-style 
terminals to access the central mainframe.

My (perhaps naive) understanding is that the xterm mappings basically 
implements a superset of VT220, which is why the "xterm R6" mapping in PuTTy 
works for our software. Since our software is doing it's own home-grown thing 
and expecting the terminal to send VT220-style keycodes, my (again perhaps 
naive) understanding is that by changing PuTTy to use "xterm R6" mode that 
tells PuTTy to always send the VT220-style keycodes regardless of the $TERM 
value.

It sounds like my work-environment situation is fairly non-standard, so feel 
free to take all of this with a grain-of-salt. I don't expect you to go out of 
your way to support an edge-case like this, especially since it's fairly easy 
to work around with AHK. Though, it sounds like there might be some value in 
respecting those VT220 enable/disable control sequences, for the more general 
case where programs are trying to opt-into VT220-mode using the standard 
control sequences.

P.S. Thank *you* very much for the detailed and prompt responses.

Original comment by tonyduck...@gmail.com on 21 Aug 2010 at 3:39

GoogleCodeExporter commented 8 years ago 
Ah, the joys of legacy systems. That's a convincing use case you've got there.

I don't really know what the history of these function key modes is or how the 
PC-style keys came to be the default, especially considering the xterm control 
sequences page says "xterm is most useful as a DEC VT102 or VT220 emulator". 
But I guess PuTTY picked up its xterm mode when the VT220 codes were the 
default.

Btw, there are at least two more keys that change keycodes in VT220 mode: Home 
and End send '\e[1~' and '\e[4~', respectively, instead of '\e[H' and '\e[F'. 
Also, xterm uses Ctrl rather than Shift to turn Fx into F1x.

Original comment by andy.koppe on 21 Aug 2010 at 8:55

GoogleCodeExporter commented 8 years ago 
Implemented in r985 and r986 on trunk. Apart from using the '\e[?1061h' control 
sequence, VT220 keyboard mode can also be enabled by setting the TERM variable 
on the (increasingly misnamed) Output page of the options to a string 
containing 'vt220'.

Please note that the application still needs to enable application keypad mode 
(DECPAM) and NumLock needs to be off for the numpad keys to send the 
'\eOx'-style sequences. As in xterm, F13 to F20 can be entered with Ctrl+F3 to 
Ctrl+F10.

Original comment by andy.koppe on 22 Aug 2010 at 12:21

GoogleCodeExporter commented 8 years ago

Original comment by andy.koppe on 3 Oct 2010 at 3:43