bug-ncurses
[Top][All Lists]
Advanced

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

Re: ISO 2022 in terminals


From: Keith Winstein
Subject: Re: ISO 2022 in terminals
Date: Thu, 3 Feb 2011 21:08:30 -0500 (EST)
User-agent: Alpine 1.10 (DEB 962 2008-03-14)

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?

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"?

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



reply via email to

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