Hrvoje> "Dan Harkless" <dan-xemacs(a)dilvish.speed.net&gt; writes: Hrvoje> At least part of the problem is that there is (or should Hrvoje> be) no such thing as a "Japanese buffer". Any buffer can Hrvoje> contain any character. XEmacs does not yet know anything Hrvoje> about specific languages, either. No, but obviously modes that do text-filling should know about them. Dan> We'll revert to the state of affairs when things worked for Dan> European languages, and then we'll accept correct fixes for Dan> Japanese. OK. Since Dan has provided an algorithm to replicate the problem, it should get fixed soon enough. Don't forget put "there are changes in this version of XEmacs that cause potential data loss for Japanese (at least) using kinsoku processing" in the ChangeLog entry, NEWS, and PROBLEMS. Dan> I don't have an xemacs built with mule, so I can't try it, Dan> but do you get lines of (fill-column + 1) columns if you type Dan> a space at fill-column in Japanese too? OK, I see this. So it's not the `(if (featurep 'mule) (kinsoku-nantoka))' calls. Pity. Dan> If so, it seems like the current code is wrong for all Dan> languages -- what about my previous suggestion that the right Dan> thing to do if you need to preserve spaces is to have Dan> auto-fill actually go back and break at the _previous_ legal Dan> fill boundary? Then the unbreakable text at the end of the Dan> line and the space after it would go down to the beginning of Dan> the next line. This would not be acceptable in Japanese. 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> There could even be a variable like Dan> [auto-?]fill-preserve-spaces or something like that that you Dan> could set in any language that would cause that behavior. If Dan> it wasn't set, the old correct (Western language) behavior of Dan> changing the space to a newline would apply. Unfortunately, people who write in Japanese often need both behaviors in the same buffer (as Hrvoje points out). Steve Baur suggested that we could do a charset test on the character at a candidate point; I think that's good enough in general. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."

Kazuo> I don't know why space must be left at the end of line in Kazuo> Japanese. Could someone tell me? Since space characters are not normally embedded in text in Japanese and other Asian languages, such usage is very personal. I have heard some Japanese, Chinese, and Korean users complain of the loss of those spaces through refilling a paragraph. AFAIK most Japanese don't care; those who do, seem to care strongly. Personally, I make a habit of setting spaces around English embedded in Japanese; this is more readable to me and to several other gaikokujin I know. It is far more annoying to me to lose that space than it is to have an extra space at the end of the occasional line in all-English text. For another example, I have seen spaces used for emphasis in the way that all uppercase is used in English. If in the process of filling and refilling, " GAI KOKU JIN " should become " GAI KOKUJIN ", the meaning taken will possibly change. I'm sure you can think of more amusing or more embarrassing examples, even if kanji are used to help disambiguate the meaning. I could write a function to check for the situation in my own usage (I use JIS X 0208 "full-width" characters for Japanese romaji, and ASCII for English, so I can distinguish those usages easily). However, I have no idea what other people who prefer to have that space left in the text are trying to do, and it may not be possible to disambiguate syntactically. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."