Re: lynx-dev 1) placement of "README.jp" 2) is "--enable-cjk" necessary

[Henry Nelson]

> > With the recent Hataguchi changes, which seem to be on by default in
> > userdefs.h, does it make sense to use the configure option "--enable-cjk"?
> > What does "--enable-cjk" do that "USE_TH_JP_AUTO_DETECT, CONV_JISX0201KANA
> > _JISX0208KANA, and KANJI_CODE_OVERRIDE" don't?
> 
> I'm sorry I don't know.

Don't apologize; you've done some fantastic work.  I asked the question
only because already there is a "pre" out in preparation for a "release,"
while this issue seems to have been overlooked.

> | 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.
> 
> I agree with this and I believe you also do.

Unfortunately I do not have anywhere near the programming skills necessary to
judge.  From a strictly user's point of view, the configure option doesn't
seem to do anything anymore -- so naturally, I wonder why it's still there.

> I've done this job partially. But I don't have time to do the rest now.

I know; school starts up today everywhere in Japan.  Anyway it's nothing
you HAVE to do as long as the remaining job is understood and known to be
pending.  Then it's just another "whenever" chunk of code.

However, if eventually CJK_EX is going to disappear, then to me anyway,
it would make more sense to not have it as a visible configure-script
option in a release, but simply stick it in userdefs.h along with your
new defines, and earmark it for eventual purging.  (I don't see that as
your, TH's, job.)

__Henry