Re: Issues with japanese support

* Ikumi Keita (2005-03-04) writes:

> I found another problem in the fill code in
> LaTeX-fill-move-to-break-point.
> ------ [A] ----------------------------------------------------------
[...]
>     (if (and (featurep 'mule)
>          (TeX-looking-at-backward LaTeX-nospace-between-char-regexp))
>          (backward-char 1)
>       (skip-chars-backward "^ \n"))
> ----------------------------------------------------------------------
> Here, the function TeX-looking-at-backward is called without a search
> limit specified.  So, in a buffer without CJK letters, the search of
> re-search-backward in that function is performed all the way back to the
> beginning of the buffer (or the narrowing region) every time
> LaTeX-fill-move-to-break-point is called in the filling loop (unless
> used with CVS Emacs, which has fill-move-to-break-point).

Yes, that's not good.

> So the relavant portion of the above [A] should be:
> ----- [B] ------------------------------------------------------------
>     (if (and (featurep 'mule)
>          (TeX-looking-at-backward LaTeX-nospace-between-char-regexp 1))
>          (backward-char 1)
>       (skip-chars-backward "^ \n"))
> ----------------------------------------------------------------------

I think this would be a good solution.

> Here are other plans.  I think the same result will be achieved by the
> following:
> ----- [C] ------------------------------------------------------------
>     (unless (and (featurep 'mule)
>              (re-search-backward LaTeX-nospace-between-char-regexp
>                                                    (1- (point)) t))
>       (skip-chars-backward "^ \n"))
> ----------------------------------------------------------------------
> I expect [C] will work faster than [B]. (However, I didn't actually
> test.)  The drawback is that [C] might be less easy to read.

We will probably not gain much, so I prefer the code which is easier
to read.

> If we consider avoiding the use of regular expressions because of its
> slowness, the following approach is possible:
> ----- [D] ------------------------------------------------------------
>     (cond
>      ((featurep 'xemacs)
>       (unless (and (featurep 'mule)
>                  (re-search-backward LaTeX-nospace-between-char-regexp
>                                                      (1- (point)) t))
>                                                      (skip-chars-backward "^ \n")))
>      (t ;; FSF Emacs 21
>       (if (aref (char-category-set (char-before)) ?|)
>         (backward-char 1)
>         (skip-chars-backward "^ \n"))))
> ----------------------------------------------------------------------
> I'm not sure this is faster than [C] with Emacs 21 since the whole
> structure grows up and the regular expression search in [C] is conducted
> over only one character.  However, [D] has a good side effect that FSF
> Emacs no more uses the variable LaTeX-nospace-between-char-regexp
> throughout latex.el, so we can omit the defcustom declaration of this
> variable with FSF Emacs.  This variable is already meaningless to CVS
> Emacs, at least currently, and shows up in the customize menu as an
> useless option now.  If we take approach [D], we can get rid of this
> situation in CVS Emacs and Emacs 21 together.

But we need the variable in `LaTeX-fill-delete-newlines' nevertheless,
so we would not gain much.  We could however consider to convert it to
a defvar instead of a defcustom.  I don't think there is much sense in
exposing this as a customizable option anyway.

-- 
Ralf