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

["John E. Davis" <davis>]

On Thu, 29 May 2003 16:40:18 -0400 (EDT), Pavel Roskin <proski@xxxxxxx> said:
>I don't program in s-lang, so I cannot comment in details on the strlen
>proposal.  I think that is needed is the width of the text as it appears
>on the terminal.  Wide glyphs should count as 2.

For jed, that is not what one wants.  Movement through the buffer is
implemented in terms of characters (not bytes).  The displayable
representation is a different issue altogether that rarely enters into
the use of the strlen function.  Also, if strlen returned the width,
then what is the width of a tab?

>I'm more interested in following questions:
>
>1) How portable is the new slang going to be?  If there is no Unicode
>support in libc, what will I need to use slang 2?

Nothing.  All the unicode support is built into slang for precisely
that reason.

>2) How will slang determine whether the terminal supports UTF-8?  Is it

The library provides a function that the application is to call to
either enable or disable UTF-8 support.  The function can be used to
disable UTF-8, to forcibly enable it, or to determine whether or not
to use UTF-8 from the environment.

>going to be the encoding part of LC_CTYPE or LANG?  Or will it be taken
>from the terminfo entry for the given TERM (i.e. there will be a separate
>terminal name)?

Under Unix, the current implementation uses LC_ALL, LC_CTYPE, and LANG
in that order.  It does not use TERM.

>3) What are considerations for the use of line-drawing characters?

Currently, in UTF-8 mode, it uses unicode line drawing characters
ignoring terminfo.

>4) ncurses can be compiled with Unicode support.  Can we expect slang 2 to
>be somewhat compatible with ncurses?

I have not looked at the portion of code yet.  I will try to make it
as compatible as I can.

I hope I have answered your questions.
Thanks,
--John