Re: Issues with japanese support

From: Ralf Angeli <[email protected]>
Subject: Re: Issues with japanese support
Date: Fri, 04 Mar 2005 23:10:10 +0100

> * 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.

I checked in the code [B].

> > 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.

Me, too.

I found two problems for fill in japanese.  I will write another
mail, later.

# I don't follow the later discussion, I'll read soot ;)

(snip)
> 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.

I agree with you.  I checked in.

---
email: [email protected]
Name:: Masayuki Ataka // (Japan)