Re: unicode (was Re: Minor error message change)

[Pavel Roskin <proski@xxxxxxx>]

On Fri, 30 May 2003, John E. Davis wrote:

> Pavel Roskin <proski@xxxxxxx> wrote:
> >Thank you for your replies.  I think we are losing an excellent chance to
> >do things right.  On the other hand, S-Lang will be in compatible with the
> >existing hacks by Debian and Red Hat, as well as with ncurses.  I hope you
> >understand the implications and I don't want to start another holy war.  I
> >guess I'll have to swallow it or make things right, and I only have time
> >for the former :-(
>
> I do not understand why you are being so negative about this.  For one
> thing, the existing hacks by Debian, Redhat, and SuSE are broken with
> no support for combining characters at all.  In fact, I am tired of
> telling slrn users that the SEGVs they are reported are due to these
> hacks and that they should link slrn against an official version of
> slang.

I should have been more clear.  It wasn't about strlen.

I mean, the right way to describe terminal capabilities is to read them
from terminfo for the given $TERM.  If the terminal supports UTF-8, it's a
property of the terminal.  This property is very important for S-Lang and
similar libraries because it means that when certain bytes are sent to the
terminal, the cursor will advance in a certain way.  The acsc capability
may also be different if UTF-8 is supported.

TERM is for terminal capabilities.  Locale is for user preferences.
Preferences can be different for different users.  I personally prefer
POSIX locale, but I still want to be able to use terminals with UTF-8
support.

If I log in from a terminal without UTF-8 support into a system that sets
LANG=en_US.UTF-8 for me, I still want to see correct output.  If I use a
UTF-8 enabled terminal and log in into an old system, I also want to see
the right thing, at least for line drawing characters.

Of course, introducing a new terminal name is not easy.  Most users today
don't know how to create an entry for the new terminal in .terminfo on the
system that doesn't have such entry already.

Ideally, the terminal with UTF-8 support should behave just like a
terminal without such support until it's switched to the UTF-8 mode.
Then I could just set TERM=xterm on old machines rather than compile an
entry for xterm-utf8.

My point is that we should be doing the right thing, cooperate and think
ahead.  A lot of ugly standards appear because developers ignore those
rules.  Cooperation means that we should approach xterm developers for
make UTF-8 support more backward compatible.

On the other hand, it may be too late to do it differently.

-- 
Regards,
Pavel Roskin