Mirrors | Updates | Feedback | Changes | Wishlist | Team
At present, the Alt key causes keys it's combined with to be sent preceded by ESC. This is interpreted as a "meta" key by GNUish programs like Emacs, but some others (notably NetHack) don't understand this convention, and expect "meta" to set the top bit of the character instead. There should probably be an option to enable this behaviour.
Interesting questions about this include:
SGT, 2005-12-23: I've just investigated xterm's answers to these questions. xterm itself has relatively little understanding of complex character sets: it operates either in "conventional 8bit mode" or in UTF-8 mode. In the former, the character set is assumed to be single-byte and the Meta key translates each low-half character into its high-half counterpart in the obvious way. In the latter mode, the Meta key translates ASCII into ISO-8859-1 and then encodes it as UTF-8 (so that, for example, Meta-a sends C3 A1 which is the UTF-8 encoding of U+00E1). xterm supports all other character sets by interposing "luit", which means that whether a Meta combination generates anything in (say) Shift-JIS will depend entirely on whether the relevant Unicode value between U+0080 and U+00FF is representable in the target character set. Meanwhile, Meta appears to do nothing at all if combined with anything not in the 00-7F range, be it a character outside that range or a multi-character sequence from a function key.
This all seems a bit chaotic: I had to work hard to get xterm to demonstrate both modes to me, although I got there in the end. Based on my findings, I think a possible specification for PuTTY which would offer all of xterm's functionality would be to have a three-way switch governing the behaviour of the Alt key. In the default mode, Alt/Meta generates a prefix ESC as it always has done. In the second mode (analogous to xterm's UTF-8 mode), it maps ASCII into the top half of ISO 8859-1, translating that as appropriate for the line codepage (so that some Meta combinations will generate nothing in some character sets) and affects nothing else at all. In the third mode (analogous to xterm's 8bit mode), it maps the low half of an SBCS into the high half, no matter what SBCS is chosen. We'd have to invent something arbitrary for the third mode to do if the line codepage were not an SBCS; probably the most sensible option is to fall back to the second mode.
Audit trail for this wish.