Re: Issues with japanese support

* Masayuki Ataka (2005-02-14) writes:

> Ikumi Keita reported me that fill fails in long or short
> japanese text in Emacs 21.4 or less (CVS Emacs is OK) [1].
> (He gave me some reports, suggestions, and patches. Thanks.)
>
> I added fixes for fill codes in latex.el.

Here are some comments regarding the changes:

| --- latex.el    11 Feb 2005 09:34:37 -0000      5.326
| +++ latex.el    14 Feb 2005 01:24:05 -0000      5.327
| @@ -2439,6 +2439,12 @@
|         ;; COMPATIBILITY for Emacs <= 21.1
|         (if (fboundp 'fill-delete-newlines)
|             (fill-delete-newlines from to justify nosqueeze squeeze-after)
| +         ;; For Japanese (FIXED on 2005-02-11)
| +         (when (featurep 'mule)
| +           (goto-char from)
| +           (while (re-search-forward "\\(\\cj\\)\n" to t)
| +             (replace-match "\\1")
| +             (setq to (1- to))))

1) The search/regexp doesn't cater for the situation where there is a
   line ending with Japanese characters and the following line starts
   with a non-Japanese character.  In this case the newline must not
   be deleted.

   Could a general rule be to delete any whitespace between Japanese
   characters in the paragraph to be filled?

2) `to' is a marker.  With the change above you are degrading it to an
   integer.  Not good.  Why does it need to be changed at all?

3) I am not sure about the performance implications of this change.
   The function to get rid of newlines in the non-Japanese case is
   `subst-char-in-region' which is implemented in C and should be
   quite fast.  The `re-search-forward-statement' is likely to slow
   things down.

4) Is it sufficient to search for \cj or are there other character
   categories which have to be treated the same way?

|           ;; Make sure sentences ending at end of line get an extra space.
|           (if (or (not (boundp 'sentence-end-double-space))
|                   sentence-end-double-space)
| @@ -2558,7 +2564,12 @@
|    ;; COMPATIBILITY for Emacs <= 21.3 and XEmacs
|    (if (fboundp 'fill-move-to-break-point)
|        (fill-move-to-break-point linebeg)
| -    (skip-chars-backward "^ \n")
| +    ;; For Japanese (FIXED on 2005-02-11)
| +    (if (featurep 'mule)
| +       (if (TeX-looking-at-backward "\\cj")
| +           (backward-char 1)
| +         (skip-chars-backward "^ \n"))
| +      (skip-chars-backward "^ \n"))

That's only a cosmetic issue, but I'd write it like this:

(if (and (featurep 'mule)
	 (TeX-looking-at-backward "\\cj"))
    (backward-char 1)
  (skip-chars-backward "^ \n"))

One probably should look forward for a Japanese character as well.

Why do you have to go a character backward?  When
`LaTeX-fill-move-to-break-point' is executed, point is at the column
specified in `fill-column'.  Isn't that the correct position in this
case?

-- 
Ralf