lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Re: lynx should respect LANG


From: Henry Nelson
Subject: Re: lynx-dev Re: lynx should respect LANG
Date: Thu, 25 May 2000 11:25:19 +0900 (JST)

> > would handle the four or so environment variables concerning encoding
> > and NLS, set paths to specific help/doc files, and be sure terminal
> > and console settings are sane could be written with less words than
> > the explanation you proposed for lynx.cfg alone, 
> 
> I doubt that very much.  If you want to uphold that claim, prove it. :)

Don't really want to argue, especially with someone as knowledgeable as
you.  ... But, although your proposal is designed for the general case,
and as such is worthwhile indeed, if I understand correctly you are
attempting to deal only with getting the "right" display character in
accordance with the LANG environment variable.  To do this absolutely
in a script takes basically three lines: unset the LANG variable, reset
it to the desired value, then execute lynx with the appropriate command
line options.

The advantage of a script, which granted could NOT be for the general
case, BUT which would quite easily act as a "plug in the values" template,
is that it could set an entire suite of environment variables, set
paths to the appropriate support files to match the environment, and
then start up a lynx which would work properly in that environment.

I think this thread started as a request from a "packager."  In my biased
opinion, they can get by with a bare-bones script which does not need
to do a lot of error recovery (which takes up all the space in a script)
because they have a known, fixed environment, just that, a package.

> Note that that "intelligent wrapper" should deal with more than just
> two languages (not just ja vs en), and should be system independent
> (not depend on specific install locations), in order to provide similar

Why?  My idea of an "intelligent wrapper" is that it would handle the
languages and systems for which service is intended or available.  A
wrapper intended for Debian-JA need do no more than that.  That doesn't
prevent me from using the same wrapper on my FMR70 running an old
Slackware, or PC9821-Bf running NetBSD -- just change the values.

> Because LANG (etc.) is an existing convention on existing systems, and
> there is an existing (and not unreasonable) expectation that locale-
> aware programs honor that convention without requiring additional wrappers.

I understand this.  What I am saying is that if the wrapper route is
chosen, then you can do a lot more than just LANG.  In my opinion, how
a person logs on to a LANG=ja machine, i.e., at the console, telnet
from the console of another Unix machine, terminal emulation program
from Windows, needs to be addressed much more than than LANG to lynx
DCS compatibility.  Setting LANG just seems so TRIVIAL to me in comparison
with stty, terminfo/termcap, curses lib, [setterm].

> Because with NLS, LANG is already used for selecting the message catalog.

I don't believe this is true.

> It's reasonable to expect that it also affects the 'display character set'
> Because is is a generic mechanisms, can deal with a wide range of locale
> names, even new ones not foreseen by a local script wrapper writer.

I don't see any great advantage of a coded mechanism over a wrapper mechanism.

> Because with a uniform mechanism, lynx-dev can deal better with problems
> that users report. E.g., we will have to ask "What is $LANG set to", rather

And a wrapper using sh is not a "uniform mechanism?"
                                         ^^^^^^^^^
I can set LANG to pretty much whatever I want, and Lynx still works.  If
I set my terminal emulator to the wrong kanji encoding then I'm in real
trouble.  But if it's worth it to you, go ahead.

__Henry

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

reply via email to

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