[Top][All Lists]

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

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

From: Klaus Weide
Subject: Re: lynx-dev 1) placement of "" 2) is "--enable-cjk" necessary
Date: Sat, 8 Apr 2000 22:00:37 -0500 (CDT)

On Sun, 9 Apr 2000, Hataguchi Takeshi wrote:
> On Wed, 5 Apr 2000, Henry Nelson wrote:
> > I think "" should go in the docs/ subdirectory rather than
> > in the top directory.
> I agree.
> > 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"?

It has always been badly named.

> > 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.

My *impression* about the current state (i.e., after those options listed
have been separated out): a variety of things, some of which are necessary
(fix bugs or shortcomings) and should be enabled unconditionally, others
of which look questionable or just plain wrong to me (sorry for being vague).
After subtracting those two classes of conditional code, I don't know whether
much (or anything) is left.

> Klaus ever (13 Jan 2000) wrote like this:
> | 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.
> I've done this job partially. But I don't have time to do the rest now.

You have done this nicely (I don't know where you think it is still
"partial", for the "extra toggle" and "X0201" questions), I am glad
you did and thank you very much.  What is currently left as CJK_EX
code should ultimately all be examined and either integrated into the
"normal" code, or changed, or discarded, whatever is right for each
piece of code.  Or if in some code pieces there's still a legitimate
configuration choice that is now covered by defining CJK_EX, that
should get a more specific name.  But that certainly won't happen
for 2.8.3, so CJK_EX is still there for now.

But what we can do - and shoud do - is give the ./configure flag a
less misleading name.  --enable-cjk-ex{,p,tra} or so.  And change
the brief description, INSTALLATION now says
        Add special logic for supporting CJK documents.
it should say something like
        Add experimental logic for CJK character sets
        (This is not necessary for CJK support, and may go away)

Note that changing it now should not affect any of the countless
DOS/Windows/VMS makefiles and build scripts, only the ./configure
method, so it's not such a big change.


reply via email to

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