PuTTY wish utf8-plus-vt100

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 · Pre-release · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Simultaneous support for UTF-8 and enough ISO-2022 sequences for VT100 line drawing
class: wish: This is a request for an enhancement.
difficulty: fun: Just needs tuits, and not many of them.
priority: low: We aren't sure whether to fix this or not.
fixed-in: 6afa955a2ebf017755af134264a9423f54b9351c (0.71)

It's been suggested that it might be nice for PuTTY to support the traditional VT100 line drawing behaviour (using ISO-2022 escape sequences such as ESC ( B, ESC ) 0, SO and SI) in the same mode as also supporting UTF-8. This would allow it to simultaneously support legacy applications which ran on a VT100 and hence never output any character value above 0x7F, and modern UTF-8-aware applications.

Markus Kuhn thinks this is wrong ("While a terminal emulator is in UTF-8 mode, any ISO 2022 escape sequences [...] are ignored"), and I (SGT) am inclined to agree, not least because the lack of easily corruptible ISO 2022 state is a useful defence against the confusion caused by accidentally spewing binary files into your standard output. On the other hand, I can see the potential utility of being able to run two classes of plausibly common application without needing a mode switch or luit. So I think that if we do this at all (which isn't clear, hence priority "low"), it should be a configurable option.

BJH points out that ISO 2022 requires that when we return from UTF-8 (by ESC % @) the ISO-2022 state must be the same as when we left, so if we did this then we'd have to keep a separate pseudo-ISO-2022 state inside the UTF-8 mode (and discard it on ESC % @, rather than preserving it until the next ESC % G).

SGT, 2018-05-12: a user sent a patch to implement this.


If you want to comment on this web site, see the Feedback page.
Audit trail for this wish.
(last revision of this bug record was at 2018-05-12 08:50:18 +0100)