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

[Uwe Brauer]

   > Hi Uwe,


   > Sorry, It's unclear to me what is the difference between those "git
   > master" and "recent master".  But anyway, I think my patch can be

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.

   > applied after the commit
   > c0f3659059a138aaf5fa610f2913035d63225bfb
   > Tassilo Horn <address@hidden>
   > 2017-02-02 07:28 +0100
   > Fix TeX-view-predicate-list-builtin predicates wrt class opts
   > .






   > Do you mean that the current master works with 21.4 with and without
   > mule?  If so, it's nice to hear that.  However, I'm afraid that it's not

Sort of,  see me remarks below.


   > the point I'd like to know.  Could you tell whether the patches attached
   > with
   > http://lists.gnu.org/archive/html/auctex-devel/2017-02/msg00008.html
   > work on your xemacs environment?  In addition, is it better to add
   > (featurp 'xemacs) test to those patches?


   > In other words, I'd like to know whether I can commit the patches as is
   > or they still need further revise for coordination with xemacs.  In
   > order to determine that, I'd like to hear from experienced xemacs users
   > like you.


Ok I understand you correctly that your patch is *not* in the git repo,
so my test was anyhow useless? I should check out the commit you
mentioned above and then apply your patch. Is this correct?
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?


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?


   > I'm sorry that I don't understand what this report means. (What is
   > the "official xemacs pkg which all the tree"? Is that different
   > from "auctex xemacs pkg"?) I don't know xemacs package system at
   > all, so please forgive me if I'm saying something nonsense.

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


In both, GNU Emacs and Xemacs one can compile the lisp files of a given
package (in the general sense, not in the sense of a package system) and
install the elc, where ever it is convenient.

There is however a different way, and that are the package systems. (I
try to use the notation pkg to destinguish).

Let us start with GNU emacs. It posses, since some time, a package
system. The corresponding files of the pkg  are installed in
$HOME.emacs.d/

Pkgs can be installed from the ELPA, MELPA and marmelade repos as far as
I know.

Xemacs package system is much older (15 years maybe) and offers two
possibilities

    -  The user can, if he wishes, compile and generate his own private
       xemacs package. However there are really no tools for generating
       such a pkg. The auctex team was generous enough to provide a
       Makefile which generates xemacs pkg. That pkg then has to be
       installed in $HOME/.xemacs/xemacs-package (a place which
       corresponds in philosophy to $HOME.emacs.d/.)

    - Then there are *official* xemacs package. These require a full
       xemacs package tree for compilation, and one (actually two)
       official package managers, who generate those packages and
       uploads them to the official places. These package might be
       different from the user home made, and, this is important, they
       have to installed system wide, say in
       /usr/share/xemacs/xemacs-package or some other place.

       Now in principle there is the *main* package manager, who is
       Norbert Koch and then each package has its own package manager, I
       am the one for auctex. It seems, on reasons nobody really
       understands, that the auctex xemacs-pkg which is generated by the
       auctex-team-makefile is incompatible with the one from the
       official xemacs package Makefile. And what is more annoying it is
       sometimes more difficult to compile the official xemacs package
       then the one provided by the auctex team.

However I would strongly suggest to take the official xemacs pkg as a
point of reference. That is if it can be compiled there, everything
should be fine.  That is what I tried to say. I can compile the official
xemacs auctex package with xemacs21.4 mule but not with 21.4. No mule.
Did I explain the issue clear enough?

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

If it is not, I will checkout the commit you recommended create a branch
and apply your patch? in the next step I will try to generate an
official xemacs pkg using xemacs 21.4 mule?

And then I will try it out with Japanese latex files you sent me? Does
this sound reasonable?

Regards

Uwe