[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ISO 2022 in terminals

From: Thomas Dickey
Subject: Re: ISO 2022 in terminals
Date: Thu, 3 Feb 2011 18:59:51 -0500 (EST)

On Thu, 3 Feb 2011, Keith Winstein wrote:

Hello Markus and Thomas,

I'm working on a UTF-8 replacement for screen-over-SSH, and was excited by Markus's paragraph at http://www.cl.cam.ac.uk/~mgk25/unicode.html#term:

  With UTF-8, it is not possible that your terminal remains switched to
  strange graphics-character mode after you accidentally dumped a binary
  file to it. This makes a terminal in UTF-8 mode much more robust than with
  ISO 2022 and it is therefore useful to have a way of locking a terminal
  into UTF-8 mode such that it cannot accidentally go back to the ISO
  2022 world.

Do you know what happened to this admirable idea? It seems like the major terminal authors have mostly relented, and now interpret ISO 2022 shift sequences again, even in a UTF-8 locale or UTF-8 mode.

xterm and ncurses are configurable.  Some places to check: vt100Graphics
resource (xterm), NCURSES_NO_UTF8_ACS (ncurses).  The defaults correspond
to the most common usage.

For the others - they're largely undocumented in this area...

ncurses has special-cased the terminal types of "linux" and "screen" (by the string in the TERM environment variable) and sends UTF-8 graphic characters to those terminals ("linux" always, "screen" sometimes). But it calls those terminals "broken" and sends ISO 2022 by default to everybody else.

A program which is documented to claim "vt100" compatibility and isn't,
is broken.

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]