Re: lynx-dev Re: current_codepage error during linking

[Klaus Weide]

On Thu, 13 Jan 2000, Henry Nelson wrote:
[Jim Spath:]
> > some of the rough spots. The codepage issue is a result of changes by
> > the main Win32 contributor (Hiroyuki Senshu) to allow Japanese language
> > displays. 

I have to take issue with the formulation "to allow Japanese language
displays".  That sounds as if there had been no support for Japanese at
all before those changes, which is far from the truth.

> > As I mentioned in an earlier post, defines for SH_EX, CJK_EX
> > and WIN_EX may overlap in come of the code.
> 
> I know Tom's already swamped, but it seems reasonable that these defines
> be properly sorted out before a release.  No one should *have to* define
> CJK or SH when all they need is WIN.  The three should not overlap.

I completely agree with all your "should"s.  I think it's unrealistic to
expect this (*all* of it) to be "properly sorted out" before the next
release, though, unless you are willing to delay that a lot.

> In general the SH define seems "flaky" to me, i.e., either it contributes
> to the "good" of Lynx for the majority of CJK or WIN users and thus should
> be kept in the code base under the appropriate define, OR it is a personal
> preference hack, and as such should be taken out of the code base and
> patched on by SH himself.
> 
> CJK should not be tied to WIN -- it is a language and encoding problem,
> and IMO should work on all platforms.  

Including this last "should", in particular.

If the (correct) choice for "Display character set" in a given situation
is "Japanese (Shift_JIS)", it may be either because Lynx is running locally
under Windows (etc.), or because the user's local display uses Shift_JIS
even though Shift_JIS is not natively known on the machine where lynx
is running (some UNIX, most likely).  The encoding should be handled
equally well in both situations, not just work well in the first.
(Correct?  I *think* I am just restating what you mean.)

> TH has recently shown that that is
> possible.  I do not think CJK should be defined by default in the WIN32
> make files; Lynx should compile effortlessly with CJK_EX commented out.

Let's distinguish between CJK and CJK_EX.  Lynx has claimed to support CJK
in some way since at least version 2-5 (or way before), without any "CJK
EXtension".  No defining of extra symbols was required to make it work (as
far as that went), and no defining of CJK_EX or similar *should* be
necessary now.

For the longest time I had thought that CJK_EX was basically just a
porting device, or merging device: that is was used to mark some
alternative sections of code, until somebody would review those sections
and decide whether to keep them "for good" (and remove the #ifdef, and
remove previous and now superseded code) or not.  I've learned more
recently that that, apparently, this isn't the case: CJK_EX is used to
also control some real configuration choices.  (At least: whether that
extra toggle is provided; and whether X0201 kana should be converted to
something else or not.)  This is a bad overloading of this one symbol with
multiple meanings.  If there is a need to make those decisions
configurable at compile-time, that should be provided for with separate
symbols.

    Klaus