* file coding system for require'd .el files depends on locale
@ 2007-08-03 12:20 David Reitter
2007-08-03 12:32 ` Andreas Schwab
0 siblings, 1 reply; 2+ messages in thread
From: David Reitter @ 2007-08-03 12:20 UTC (permalink / raw)
To: bug-gnu-emacs; +Cc: Carson Reynolds
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: file coding system for require'd .el files depends on locale
2007-08-03 12:20 file coding system for require'd .el files depends on locale David Reitter
@ 2007-08-03 12:32 ` Andreas Schwab
0 siblings, 0 replies; 2+ messages in thread
From: Andreas Schwab @ 2007-08-03 12:32 UTC (permalink / raw)
To: David Reitter; +Cc: bug-gnu-emacs, Carson Reynolds
David Reitter <david.reitter@gmail.com> writes:
> 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.
Use a coding tag (*Note (emacs)Specify Coding::).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-08-03 12:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-03 12:20 file coding system for require'd .el files depends on locale David Reitter
2007-08-03 12:32 ` Andreas Schwab
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).