Re: lynx-dev changes for Japanese (was: dev.16 patch)

[Henry Nelson]

> > I checked the behavior with half width katakana 
> > and wrote a patch for dev.16.
> 
> It's great to see development of this on lynx-dev.

I'll second that.  All I can add is one big THANK YOU.

> SUPPORT_MULTIBYTE_EDIT seems to be defined only in two of the
> Windows-specifc makefiles, makefile.msc and makefile.bcb, and
> nowhere else.  It is not mentioned in INSTALLATION, README.defines,
> not explained in the makefiles, not ifdef'd with any *_EX, and I
> couldn't find it mentioned in CHANGES, so I wonder where it's coming
> from.
> 
> Anyway, it uses a hardwired IS_KANA macro that seems to be completely
> Shift_JIS specific.  I think it should test the current display

If it's Windows specific, it would be Shift_JIS specific.  I could be
wrong, but I believe another name for Shift_JIS is MS_Kanji, the MS of
course being Microsoft, the "perpetrator" of Shift_JIS.  Solaris docs
say that "Shift_JIS" is being phased out, and that the encoding should
be referred to as "PC_Kanji," or PCK for short.

> But I don't understand who needs the SUPPORT_MULTIBYTE_EDIT code.  It
> seems to me every CJK charset user should need it, is that not the case?
> If it's true, then there shouldn't even be a special macro
> SUPPORT_MULTIBYTE_EDIT.  And it should of course not be Windows-specific.

I'm not the one to be responding since I don't understand what is going
on, but if SUPPORT_MULTIBYTE_EDIT has to do with Lynx's own line editor
that one would use to enter at prompts like "g" or the "Subject:" line
offered with mailto:s, then AFAIK Lynx is broken, and has been that way
for quite some time as far as entering anything in Japanese, either EUC
or Shift_JIS.

This would have to do with dired, I suppose, but I am pretty sure that
Hiroyuki added code to deal with directories and files on disk named in
Japanese, some of which are (can you believe how nasty MS can be) by default
named in one-byte kana on Windows95/98.

> with CJK display character sets.  What happens when you delete, for
> example with the backspace key, one half of a multibyte character, without
> that special code?  Does it work at all?

Well, I use Lynx over a terminal emulation, and these days exclusively in
a "screen" virtual window, and I can say some "weird" things can show up
on the display.  From what you seem to be saying, I don't have the code
since I am compiling on Unix.  Sometimes the cursor will "jump over" one
byte and create a blank space where it rests; sometimes the cursor will
not move and the two-byte kanji will change to a different one.

> > but it doesn't if not defined because half width katakana can be
> > in the screen. I think Lynx should always convert half width katakana 
> > into full width. Are there any side effects?
> 
> Maybe with alignment of preformatted text, including text/plain?
> 
> Should this be a separate (configuration?) option, rather than everything
> being covered by CJK_EX?

I would vote for everything under CJK_EX with no option, or perhaps
eventually do away with CJK_EX entirely and have one default CJK.

If there are side effects, I think the code that results in them should
be changed, not the choice to "convert half width katakana into full
width."  As much as I enjoy half-width kana when using a word processor,
I question it's value on the Web, especially for a character cell, non-GUI
browser like Lynx.

(Maybe this doesn't interest anyone, but AFAIK, converting half-w to
full-w kana is often referred to as "X0201 kana to X0208 kana conversion."
Another good reference on Japanese code sets might be to get the "nkf"
package since you would have both the source code and an English man
page.)

> Is it too hard to deal with half width katakana in all the necessary
> places, rather than "forbidding" it?  I assume it would be a lot of

Instead of looking at it as "forbidding," I'd prefer to look at it as a
"practical way to provide portability."

__Henry