Re: ISO 2022 in terminals

[Thomas Dickey]

On Thu, 3 Feb 2011, Keith Winstein wrote:

> On Fri, 4 Feb 2011, Tim Allen wrote:
>
> > On Thu, Feb 03, 2011 at 01:58:42PM -0500, Keith Winstein wrote:
> > > Is there any progress on finishing the move to UTF-8 so we can turn
> > > off the interpretation fo ISO 2022 sequences, or did it turn out
> > > this was a bad idea?
> >
> > The trouble is that existing terminal emulators, and existing
> > terminal-using programs, aren't trying to target a hypothetical
> > 'best-practices terminal', they're targetting actual hardware terminals
> > that supported ISO2022 sequences (or in the case of more modern attempts
> > like gnome-terminal, targetting xterm which targets actual hardware
> > terminals). A pure UTF-8 terminal protocol is certainly possible, but
> > compatibility concerns[1] would make it pretty frustrating to use.
>
> Tim, that's fair, but from my point of view we already broke compatibility by 
> going to UTF-8.
>
> A "UTF-8 vt220" is already a break with the vt220 -- e.g. if you send a raw 
> C1 control it will not work, since the UTF-8 is below the ECMA-48/vt220 
> layer. Now to mention a raw GR char.
>
> Apparently Markus Kuhn was hoping (well, his page still says) that the world 
> would declare that a "UTF-8 vt220" also would refuse to honor ISO 2022 shift 
> sequences and would require UTF-8 for everything, including ACS characters.
>
> Which does not seem that crazy -- if applications have to be locale-aware to 
> generate C1 controls and GR characters in the proper encoding, why not 
> require them to be locale-aware to generate ACS characters?

so it would seem - but real terminals weren't locale-sensitive...

> Sounds like it didn't work out that way, though.
>
> > If you're willing to settle for merely not having to implement ISO 2022 
> > yourself, rather than erasing it completely, have you tried luit?>
> >         http://invisible-island.net/luit/
>
> Yeah, implementing the vt220 shifts isn't the problem -- I just was hoping to 
> be able to free the user from the possibility of getting locked into an 
> alternate charset and having to type "reset".
>
> I could have it set NCURSES_NO_UTF8_ACS=1, but that won't be carried over an 
> SSH connection (only TERM and sometimes LANG/LC_* are).
>
> Another question: Let's say I did make a new terminfo entry and you guys 
> agreed to carry it in the terminfo database. Is there anything that one can 
> put in the terminfo entry that gets this behavior (equivalent to 
> NCURSES_NO_UTF8_ACS=1), or do you really just have to have the _name_ 
> "linux"?

Well, it was "linux" only at first, since it was an exception.
"screen" crept in later, and then PuTTY (which is where I added
the environment variable).  I could add a terminfo flag, but
hadn't seen a limitation for the environment variable.

A terminfo flag would be only recognized by ncurses, anyway.

(none of the other curses implementations recognize ncurses' extended
features).

> I tried removing the smacs and rmacs capabilities but ncurses still seems to 
> send ISO 2022 escape sequences. Perhaps there could be a new terminfo 
> capability that indicates that the terminal requires UTF-8 for ACS characters 
> and will not honor ISO 2022?
>
> Thanks for your help,
> Keith

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net