Sven Joachim <[EMAIL PROTECTED]> writes: > On 2008-06-02 14:24 +0200, Sven Joachim wrote: > >> On 2008-05-31 15:31 +0200, Sebastian P. Luque wrote: >> >>> I did a `check-parens' on tthe offending file >>> (/usr/share/emacs/site-lisp/auctex/tex-jp.el), which indicated that >>> there is at least one unmatched parenthesis. >> >> Actually, that is not the problem. Rather, emacs-snapshot misreads this >> file as UTF-8 instead of iso-2022-jp. > > Which is a regression in this snapshot that has just been fixed in the > Emacs trunk. > >> I don't know which changes in Emacs are responsible for that (the >> problem did not exist in the 20080510-1 snapshot and earlier versions), >> but in any case tex-jp.el should have a coding cookie, e.g. a first line >> that reads like this: >> >> ;;; -*- coding: iso-2022-jp -*- >> >> Adding this at the beginning of tex-jp.el lets emacs-snapshot configure >> itself successfully. > > I still think that adding the cookie would be best, but that's for > upstream to decide; the Debian bug can probably be closed anyway.
The upstream AUCTeX maintainer (well, I) wants to leave things as they are. Next time this problem triggers, we will be able to report it timely to Emacs upstream. One problem with coding cookies is that the files are also compiled when using XEmacs, and XEmacs partly has different coding names. So a change here could also break things, while merely pasting over a transitory problem. -- David Kastrup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
