"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> Not really relevant to the list anymore.
It seems like very relevant info to me, especially the discussion of the
right-justification issue below. Pardon me if I send this to the lists.
> >>>>> "Dan" == Dan Harkless <dan-xemacs(a)dilvish.speed.net> writes:
> Dan> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> MIS-attributes!
> Dan> Uh, no, I did not write the above. That was Hrvoje as well.
> Very sorry. My bad.
> >> OK. Since Dan has provided an algorithm to replicate the
> >> problem, it should get fixed soon enough.
> Dan> Actually, I provided an algorithm to replicate the problem
> Dan> back in April of '98, but I guess my bug just got recorded
> Dan> then forgotten about, rather than becoming a topic of
> Dan> discussion on xemacs-beta.
> I didn't see it, or didn't notice it (I'm mostly interested in Mule).
I just posted my bug to comp.emacs.xemacs. Steven Baur then replied that he
had recorded it.
> I'm not referring to your usage, anyway. I don't like it when threads
> get introduced into xemacs-beta in the middle just so that people can
> bitch about Mule.
xemacs-beta or xemacs-mule?
> (That probably wasn't the intent, but since whoever
> diverted the thread - Hrvoje, Jan - didn't explain anything about the
> mechanics of the bug, that was the effect.)
My recent comp.emacs.xemacs post (which was apparently what was forwarded)
explained it in brief and included a URL to my original comp.emacs.xemacs
bug report, which explained it in more detail.
> >> This would not be acceptable in Japanese.
> Dan> Why not? If a space is so important, wouldn't it be better
> Dan> to _not_ have it at the end of a line, where it's invisible?
> Because you want it to reappear when refilling takes place. Using ^
> and $ to mark line beginning and end of lines:
> Using spaces for emphasis:
> ^StartWithPunctuation, Including Explicit $
> ^ouldNotStartWithPunctuation, Including E$
> ^xplicit WhiteSpace.$
> See how the space between "explicit" and "whitespace" comes back?
I'm not advocating removing it. I was suggesting:
^StartWithPunctuation, Including $
And if "Including Explicit WhiteSpace" is in romaaji, which I take it is the
most common usage of explicit whitespace in Japanese writing, you can't
always avoid that ragged right side (in fixed-width text), so the above
should be acceptable.
If "Including Explicit WhiteSpace" is Japanese, however, I finally see why
one might want to put the space past fill-column. Nobody had brought up
this right-justification issue until now (or if they did, I missed it).
However, if you're using explicit white space in Japanese, you can't have a
clean right side in all cases -- what about:
^StartWithPunctuation Including Explicit $
> >> I think it would be pretty unacceptable in English too (people
> >> will go nuts with three-letter words that don't fit into four
> >> letter spaces at the end of the line).
> Dan> Yeah, I know some people would find it unacceptable --
> Dan> that's why I was proposing it be controlled by a variable
> Dan> that you can set either way. But I think you may be
> Dan> overestimating the number of people who'd find it
> Dan> unaccepable anyway -- look how long this extra space bug has
> Dan> persisted...
> I think you're underestimating the number of people who can visually
> estimate the length of the word "the" but can't see empty space.
In all my non-email, non-newsgroup-post buffers, I set the fill-column to 80
(and have my XEmacs window 81 columns wide -- an annoying necessity), so
anytime there's an extra space at the end of the line, I see the line-wrap
"curly arrow", not just "empty space".
I'd think most people would want to use all of the columns they're entitled
> Only people who are writing to strict coding standards with automatic
> checking software are likely to find the bug "highly" annoying. (A
> few people will naturally find it a pain in the neck, of course, but
> they will be few.)
No, like I say, anyone who has fill-column set to the width of the window
> Dan> That's a fundamental failure in what auto-fill
> Dan> claims to do, and it's been broken ever since 20.0.
> Documentation? Info says "break at appropriate places".
> "Appropriate" is culturally determined, eg, by company coding
Okay, you got me there. I didn't re-read the documentation before saying
that, and I was remembering it as being defined mechanically in terms of
> >> Unfortunately, people who write in Japanese often need both
> >> behaviors in the same buffer (as Hrvoje points out).
> Dan> Hmmm. Do they *need* both behaviors? I still fail to see
> Dan> what's so bad about breaking at the previous boundary if
> Dan> you've specifically told xemacs you want to preserve spaces.
> Yes. The above text is how many Japanese write English embedded in
> Japanese (except that they wouldn't use capitals to indicate word
> breaks as I did). Such authors don't need both. That is not
> acceptable in most academic writing, however; the English should look
> like English. Such embedding is an everyday occurance, the need is
With the right-justification issue in play, I now understand how this could
be the case.
> Dan> So what'll happen? In Asian languages, auto-fill will fail
> Dan> to perform as advertised, allowing you to get lines of
> Dan> (fill-column + 1) columns, whereas in Western languages, that
> Dan> won't be the case?
> Yes. It's not just the magic space, it's all punctuation. Lines may
> not start with punctuation. There are two styles. In one,
> punctuation at the end of the line is retained, resulting is lines
> going past the fill column. Most Japanese texts seem to do this. (In
> fact, I have seen proportionally filled text with exdented
Wow. Sounds pretty ugly. If that's common usage, however, especially in
printed material, that really changes things. I thought we were just
talking about two different views of "getting all the columns one is
entitled to" in XEmacs.
> This style is often seen in programming (the exdented
> "*/" terminator, right?) by Westerners, too.
But the "*/" doesn't go past fill-column.
> I believe that some old style manuals recommend this style for English,
> too. The alternative style is to have some short lines, as in English.
> This is pretty ugly, IMHO, and evidently most Japanese agree.
Or to have variable-width spaces (or multiple spaces in series in a
> Dan> Seems pretty hokey to me
> Please. If you don't understand the language, don't go there. Shall
> we start on English spelling?
I didn't mean the Japanese usage seemed hokey, I meant XEmacs' definition of
fill-column and auto-fill seemed hokey, if it was only trying to artifically
gain Japanese users 1 extra column in certain situations. Again, the
right-justification bit definitely changes my understanding of the issue.
> Dan> I know it'd bug the heck out of me if I had fill-column set
> Dan> to 80 and was working on a buffer of C code with Japanese
> Dan> comments (I had to do this frequently at my previous job),
> Dan> and the C code would auto-fill properly, but the Japanese
> Dan> comment lines would occasionally be 81 columns, breaking my
> Dan> company's coding style policy, and me with no way to stop
> Dan> that from happening.
> Well, your company's coding style policy conflicts with the relevant
> national standard, then. (AFAIK it is in fact a Japanese national
> standard that specifies the two styles of line breaking.) I believe
> both are supported by Mule....
> ...Yes. (setq kinsoku-extend-limit 0) does what you want.
> Except that it probably doesn't in the pre-Hrvoje-reversion-code, as
> that variable only exists in Mule. So obviously the behavior you
> reported is a bug. (Please note that nobody bothered to say that this
> behavior introduced to support Asian languages was occurring in
> non-Mule XEmacsen, either; even you only noted it as a "by-the-way"!)
Well, that was discussed, but yes, perhaps could have been stressed more.
However, I wouldn't want the spaces past fill-column just because I had
built my XEmacs with MULE support (but wasn't actively using it).
Dan Harkless | To prevent SPAM contamination, please
dan-xemacs(a)dilvish.speed.net | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.