PuTTY bug xterm216-altfn-escape

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Alt + Fn in Xterm 216+ mode sent an unwanted prefix escape on Windows
class: bug: This is clearly an actual problem we want fixed.
absent-in: c35d8b832801d926a16ad29c416b969654051ef0
present-in: b13f3d079b66f25d26179185c65d40b348b4b570
fixed-in: 89c88253f61ffb3112ef5935108eca2f5e7197df (0.82)

In general, PuTTY's terminal handles the Alt modifier key by prefixing the Escape character to whatever it would have sent for the key you pressed with Alt. For example, Alt + b sends ESC and then b.

For most function and arrow keys, in most modes, this works just the same. For example, in PuTTY's default function key mode (labelled "ESC[n~"), the F6 key sends ESC followed by the text "[17~", and if you press Alt + F6, then you get an extra ESC, so two copies of the ESC character followed by "[17~".

However, the "Xterm 216+" function key mode incorporates modifier text into the escape sequence indicating whether Alt was pressed: on a modern xterm, F6 sends ESC [17~ and Alt + F6 sends ESC [17;3~, where the extra parameter 3 indicates a combination of modifier keys (in a confusing way) that can include any of Ctrl, Shift or Alt.

Therefore, PuTTY should not also send an extra prefix ESC: in this mode, Alt + F6 should send just ESC [17;3~, not ESC ESC [17;3~.

In 0.81 and before, on the Windows platform, it sent the latter.


If you want to comment on this web site, see the Feedback page.
Audit trail for this bug.
(last revision of this bug record was at 2024-11-18 11:44:43 +0000)