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

[Thomas Dickey]

On Sun, May 28, 2000 at 10:11:17PM -0500, Klaus Weide wrote:
> 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?

yes.  The only features lost in the different version are some attribute
bits that aren't used by ncurses (A_PROTECT, etc.).  It does require a
recompile because the A_xxx assignments differ.
 
> I assume multibyte characters have to be fed to waddstr() etc. in one
> piece, rather than several waddch(), but that's already done.

addchstr accepts wide characters directly (but of course building the
string is awkward).  A real multibyte interface is something different -
I can see roughly how it would be put together to fit with the X/Open
documentation, but that will require a change to the underlying data
structures, not simply moving bits around.  (The X/Open documentation is
vague in this area, I suspect because the people writing it had not
actually seen it implemented ;-)
 
> 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.

yes - in this instance I would have provided the flexibility, but I see that
slang initializes internal variables _once_ which would have to be altered
after initialization to make this feature work.  So I left the note for
whoever would be interested in modifying slang.
 
> (I'd like to be able to continue using EXP_CHARTRANS_SWITCH in lynx.)

there's no immediate danger of making EXP_CHARTRANS_SWITCH obsolete.
 
> (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)

The issue about switching is mainly one of getting the streams flushed
properly if xterm might switch to/from tek4014 mode - I haven't spent the
time in that area, since as usual there are other things piled on top
of it that are a distraction.

>   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

-- 
Thomas E. Dickey <address@hidden>
http://dickey.his.com
ftp://dickey.his.com

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