Re: [AUCTeX-devel] Fix for tex-jp.el

[Ikumi Keita]

Hi Uwe,

> Ok I am using usually HG and therefore I am not so familiar with git's
> terminology. I meant the master branch and the most recent commit, (tip
> for HG), I think it is called HEAD in git.

Thanks, and now I realize that the point of your question was whether
the patch of the topic was *already* in the git repository or not.  The
difference of "git master" and "recent master" wasn't important.  I'm
sorry for not noticing that.

(By the way, I'm using HG, too.  To tell the truth, I'm not familiar
with git's terminology, either.)

> Ok I understand you correctly that your patch is *not* in the git repo,

That's right.  It isn't committed yet in the git repo.

> I should check out the commit you mentioned above and then apply your
> patch. Is this correct?

Yes, correct.  (More precisely, the revision (in the terminology of
mercurial) that you should check out is not limited to the
changeset:   6974:287719ae870f
user:        Tassilo Horn <address@hidden>
date:        Thu Feb 02 07:28:48 2017 +0100
summary:     Fix TeX-view-predicate-list-builtin predicates wrt class opts
.  Any revision after that will equally be OK.)

> What is with the commit

> commit 9876030e88a67c36b567df20d5c3235d36ab3b45
> Author: Ikumi Keita <address@hidden>
> Date:   Sat Feb 4 17:39:30 2017 +0900

>     Fix minor problems
>     * tex.el (TeX-view-predicate-list-builtin): Enclose whole alternatives
>     in regexp with shy group in order that the effect of "\`" and "\'"
>     covers all the alternatives.
>     * latex.el (LaTeX-auto-cleanup): Regard "Class", in addition to
>     "class", as an indicator of LaTeX2e document.

> That is *not* the one you mean?

No, it isn't.  The change you quoted was approved and installed in the
git repository already.  This thread, which began with
http://lists.gnu.org/archive/html/auctex-devel/2017-02/msg00008.html
, discusses whether the changes which are *not* yet in the git repo
should be approved or not.

> Ok some comments (that might become long, but I think it is important to
> sort it out).

(snip)

> Did I explain the issue clear enough?

Yes, thank you.  Now I have an overview clear enough to understand your
report.

> And you not only want me to compile it but to use and to run it? If so
> should I do it for Japanese tex files? Unfortunately I don't speak
> Japanese, so maybe you could send me some test files, which I could try
> to modify and compile?

Ah, no, I'm not going to ask a non Japanese-speaker to do such a
complicated task.

> So how shall we proceed? First is your patch in the auctex git repo, or
> not? Please confirm this.

I think I have done it in the former half of this mail.

> If it is not, I will checkout the commit you recommended create a branch
> and apply your patch?

Yes, please.

> in the next step I will try to generate an official xemacs pkg using
> xemacs 21.4 mule?

I think it is not necessary.  Rather than that, could you please
clarify the point stated in
http://lists.gnu.org/archive/html/auctex-devel/2017-02/msg00015.html
?  That is, does the existence of the functions
`get-coding-system-from-locale' and `current-locale' depend on the mule
feature?  Is it independent of the xemacs version (21.4, 21.5)? 

In addtition, I would appreciate if you have answers to the following
questions and could kindly tell them to me: Does xemacs have a simple
and reliable way to know the coding system accomanying the locale?
If so, how?  I proposed a way of
                            ((fboundp 'get-coding-system-from-locale)
                             (get-coding-system-from-locale
                              (current-locale))))))
to do the job for xemacs, but I would like to know if this is
appropriate, and to know a better way if exists.

Regards,
Ikumi Keita

P.S. By the way, speaking of the topic that xemacs 21.4 without mule
fails to compile the official xemacs pkg, isn't it due to some errors
during byte-compiling tex-jp.el?  Then, it might be solved by removing
tex-jp.el from the target of byte compilation.  That is what
AUCTeX-team-Makefile does when the given emacsen lacks mule feature.
The file tex-jp.el contains full of Japanese text in its non-comment
part encoded in the coding system iso-2022-jp, which will be an obstacle
that non-mule emacsen can never overcome because of the nature of that
coding system.