unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: David Reitter <david.reitter@gmail.com>
To: bug-gnu-emacs@gnu.org
Cc: Carson Reynolds <carson@k2.t.u-tokyo.ac.jp>
Subject: file coding system for require'd .el files depends on locale
Date: Fri, 3 Aug 2007 07:20:05 -0500	[thread overview]
Message-ID: <8788A74F-CE8C-41B6-9A4B-96288153407E@GMAIL.COM> (raw)

I've encountered an issue with a source file being loaded by  
"require" using an coding system that depends on the machine's locale.
The source file was decoded with the wrong coding system on a  
Japanese (OS X) machine and, subsequently, produced the error below.

I find this behavior inconvenient, because a "require" or "load"  
often applies to files developed and tested under a different locale,  
where the coding system is guessed correctly. I would like to have a  
guarantee that my source file is decoded consistently, no matter what  
the locale is.

The error that occurred was:

Debugger entered--Lisp error: (invalid-read-syntax ") or . in a vector")
   eval-buffer(#<buffer  *load*> nil "/Users/dr/A.app/Contents/ 
Resources/site-lisp/macosx/emulate-mac-keyboard-mode.el" n$
   (let ((load-file-name fullname) (set-auto-coding-for-load t)  
(inhibit-file-name-operation nil)) (with-current-buffer b$
   (unwind-protect (let (... ... ...) (with-current-buffer  
buffer ... ... ...) (eval-buffer buffer nil ... nil t)) (let ($
   (let* ((buffer ...) (load-in-progress t) (source ...)) (unless  
nomessage (if source ... ...)) (when purify-flag (push $
   (if (null (file-readable-p fullname)) (and (null noerror)  
(signal ... ...)) (let* (... ... ...) (unless nomessage ...)$
   load-with-code-conversion("/Users/dr/A.app/Contents/Resources/site- 
lisp/macosx/emulate-mac-keyboard-mode.el" "/Users/d$
   require(emulate-mac-keyboard-mode)


If the file is visited manually on the Japanese machine, buffer-file- 
coding-system  is `japanese-shift-jis-unix'.
On my locale, it is `iso-latin-1-unix' (correct).

The output of C-h C on the Japanese machine is attached to the end of  
this message.

The file being loaded can be inspected here:
http://aquamacs.cvs.sourceforge.net/*checkout*/aquamacs/aquamacs/src/ 
site-lisp/macosx/emulate-mac-keyboard-mode.el

Finally, my workaround for this is to do

  (let ((coding-system-for-read 'iso-latin-1-unix))
     (require 'emulate-mac-keyboard-mode))

I guess I could have defined the coding system in the file directly,  
or I could have byte-compiled it.

Thanks to Carson Reynolds at U Tokyo for helping me track this down.


Coding system for saving this buffer:
   - -- undecided-unix

Default coding system (for new files):
   E -- euc-jp-unix (alias of japanese-iso-8bit-unix)

Coding system for keyboard input:
   M -- mac-roman

Coding system for terminal output:
   1 -- iso-8859-1 (alias of iso-latin-1)

Defaults for subprocess I/O:
   decoding: E -- japanese-iso-8bit (alias: euc-japan-1990 euc-japan  
euc-jp)

   encoding: E -- japanese-iso-8bit (alias: euc-japan-1990 euc-japan  
euc-jp)


Priority order for recognizing coding systems when reading files:
   1. japanese-iso-8bit (alias: euc-japan-1990 euc-japan euc-jp)
   2. iso-2022-jp (alias: junet)
   3. japanese-shift-jis (alias: shift_jis sjis cp932)
   4. iso-2022-jp-2
   5. iso-latin-1 (alias: iso-8859-1 latin-1)
   6. mule-utf-8 (alias: utf-8)
   7. mule-utf-16be-with-signature (alias: utf-16be-with-signature  
mule-utf-16-be utf-16-be)
   8. mule-utf-16le-with-signature (alias: utf-16le-with-signature  
mule-utf-16-le utf-16-le)
   9. iso-2022-7bit
   10. iso-2022-8bit-ss2
   11. emacs-mule
   12. raw-text
   13. chinese-big5 (alias: big5 cn-big5 cp950)
   14. no-conversion


   Other coding systems cannot be distinguished automatically
   from these, and therefore cannot be recognized automatically
   with the present coding system priorities.

   The following are decoded correctly but recognized as iso-2022-jp-2:
     iso-2022-7bit-ss2 iso-2022-7bit-lock iso-2022-7bit-lock-ss2  
iso-2022-cn iso-2022-cn-ext iso-2022-kr

Particular coding systems specified for certain file names:

   OPERATION     TARGET PATTERN          CODING SYSTEM(s)
   ---------     --------------          ----------------
   File I/O      "\\.dz\\'"              (no-conversion . no-conversion)
                 "\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'"
                                         (no-conversion . no-conversion)
                 "\\.tgz\\'"             (no-conversion . no-conversion)
                 "\\.tbz\\'"             (no-conversion . no-conversion)
                 "\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'"
                                         (no-conversion . no-conversion)
                 "\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'"
                                         (no-conversion . no-conversion)
                 "\\.elc\\'"             (emacs-mule . emacs-mule)
                 "\\.utf\\(-8\\)?\\'"    utf-8
                 "\\(\\`\\|/\\)loaddefs.el\\'"
                                         (raw-text . raw-text-unix)
                 "\\.tar\\'"             (no-conversion . no-conversion)
                 "\\.po[tx]?\\'\\|\\.po\\."
                                         po-find-file-coding-system
                 "\\.\\(tex\\|ltx\\|dtx\\|drv\\)\\'"
                                         latexenc-find-file-coding- 
system
                 ""                      (undecided)
   Process I/O   nothing specified
   Network I/O   nothing specified

             reply	other threads:[~2007-08-03 12:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-03 12:20 David Reitter [this message]
2007-08-03 12:32 ` file coding system for require'd .el files depends on locale Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8788A74F-CE8C-41B6-9A4B-96288153407E@GMAIL.COM \
    --to=david.reitter@gmail.com \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=carson@k2.t.u-tokyo.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).