From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020606 Description of problem: The AucTeX package as included in XEmacs defaults to using the (non-existant) "jlatex" binary (instead of "latex") and displays explanatory error messages by default in Japanese. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Make sure you have (require 'tex-site) in init.el [to activate auctex] 2. start "xemacs" 3. Load a LaTeX file with a non-standard document class (eg, Springer's llncs style) 4. Type C-c C-c *** first bug: Default choice is jLaTeX instead of LaTeX 5. Type "LaTeX<return>" *** second bug: AucTex uses the "jlatex" binary instead of "latex" 6. Evaluate (setq TeX-command-list (cons (list "LaTeX" "latex '\\nonstopmode\\input{%t}'" 'TeX-run-LaTeX nil t) TeX-command-list)) to get around the above two problems 7. Introduce an error into your LaTeX file and compile *** third bug: explanatory error message is in Japanese Actual Results: See the lines marked with *** above Additional info: I had a quick look at the relevant Elisp sources and at least part of the problem is that the file tex-jp.el (of the AucTeX sources) assumes that any Emacs that has mule compiled in must be that of a person who by default wants to use Japanese (the third bug can certainly be attributed to this). This assumption is flawed as (1) RH7.3 ships XEmacs by default with mule enabled and (2) some people want to have support for Japanese enabled in XEmacs, but use it only occassionally and certainly not for error messages produced by vanilla LaTeX. The first bug seems to be more subtle. It occurs only when a non-standard document class is used. Presumably, as AucTeX inspects the document class to determine which version of LaTeX to run. "jlatex" seems to be a bad default to fall back on when the document class is not recognised. The second bug is related to the %l option defined in the variable TeX-expand-list in tex.el and the associated function TeX-style-check. It causes AucTeX to choose "jlatex" even when "LaTeX" (and not "jLaTeX") is chosen at the C-c C-c prompt. Workaround: My current *crude* workaround is to include the following in .xemacs/init.el: (require 'tex-site) (require 'tex) (setq TeX-command-list (cons (list "LaTeX" "latex '\\nonstopmode\\input{%t}'" 'TeX-run-LaTeX nil t) TeX-command-list)) (setq japanese-TeX-error-messages nil)
Do you have a file demonstrating the problem? I can't reproduce it with a standard tex file.
I don't seem able to reproduce this either.
I finally found a very simple way to reproduce the problem, which at least works on RedHat 8.0 (I don't have a 7.3 box to test this anymore). 1) Start xemacs with "xemacs -q" 2) Type Esc : (require 'tex-site) [Here "Esc :" means the two keys "Esc" and ":".] 3) Load the file foo.tex, which I attach to this bug report 4) Type C-c C-c Now you will be presented with the default of running jLaTeX. Even if you ignore this default and type latex<Enter>, xemacs will still try to run jLaTeX. Analysis: It is the first letter of the name of the document class that triggers the errorneous behaviour. The document class "jfp", which I use in the attachment, is the standard class for articles for the Journal of Functional Programming (and has nothing to do with the Japanese language). Work around: Changing the \documentclass{jfp} into \documentclass{ jfp} (i.e., adding a space character after the opening brace) defeats auctex's crude algorithm for determining whether a class file needs Japanese LaTeX, but doesn't bother LaTeX.
Created attachment 84964 [details] Example LaTeX file triggering the bug
Ah, thanks for pinning it down. (Of course it should be running platex and not jlatex for Japanese LaTeX but that is another issue I guess :-)
Ok, the culprit was TeX-format-list (tex.el) whose default car is ("JLATEX" japanese-latex-mode "\\\\\\(documentstyle[^%\n]*{j\\|documentclass[^%\n]*{j\\)") Should get fixed in the next package release (21.4.10-3).
This is included in xemacs-21.4.10-3, but actually the patch is not applied; during the build there's a message: + patch -b .jltx patch: **** Can't find file .jltx : No such file or directory I guess the -b option of patch doesn't take an argument.
Yep, I messed up the patch command, and rpmbuild just went on regardless :-\ Should get properly fixed in next package release, thanks.
Should be fixed in 21.4.10-5. Thanks.