lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Emacs + UTF-8 + Lynx


From: Klaus Weide
Subject: Re: lynx-dev Emacs + UTF-8 + Lynx
Date: Sun, 28 May 2000 22:11:17 -0500 (CDT)

On Sun, 28 May 2000, Thomas Dickey wrote:

> On Sun, May 28, 2000 at 08:18:03PM -0500, Klaus Weide wrote:
>  
> > In an ideal world, UTF-8 capable versions of curses and slang
> > would be interface-compatible with previous versions.
> 
> yes/no - it's the same interface, but requires a different copy of libncurses
> (libncursesw) which accepts 16-bit characters in the functions that manipulate
> chtype's rather than 8-bit characters, such as addchstr.

So if lynx doesn't use those for output (it doesn't afaik), and didn't
use winch()-like functions for getting characters already output (it
doesn't seem to, either) - it should work without code changes?

I assume multibyte characters have to be fed to waddstr() etc. in one
piece, rather than several waddch(), but that's already done.

> That ability (to accept 16-bit characters) can be easily tested with an ifdef,
> and the library itself initializes UTF-8 if that string appears in the locale
> variables ($LANG, etc).

Yet another overloaded use for $LANG etc...  But in line with what
I was suggesting in another thread.

You should also provide an interface for changing mode at runtime.
To quote yourself :)  (see LYReadCFG.c)
    /*
     * Sorry - the order of initialization of slang precludes setting the
     * default colors from the lynx.cfg file, since slang is already
     * initialized before the file is read, and there is no interface defined
     * for setting it from the application (that's one of the problems with
     * using environment variables rather than a programmable interface) -TD
     */
Different problem of course, but same issue of environment variables
vs programmable interface.

(I'd like to be able to continue using EXP_CHARTRANS_SWITCH in lynx.)

(More generally, applications can switch locales at runtime.
As far as changes purely in character encoding (not language etc.)
are concerned, this could be useful
  a) in xterm, if it supported switching from/to -u8 mode at
     runtime (some apps can't handle UTF-8 output, so need switching)
  b) as a) but for linux console (but UTF-8 support is limited)
  c) for running applications under somwthing like screen -
     connect with an ISO-8859-1 terminal, reconnect from somewhere
     else with a terminal in UTF-8 mode, etc., while keeping the
     app running.)

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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