From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.bugs Subject: file coding system for require'd .el files depends on locale Date: Fri, 3 Aug 2007 07:20:05 -0500 Message-ID: <8788A74F-CE8C-41B6-9A4B-96288153407E@GMAIL.COM> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1186143634 29016 80.91.229.12 (3 Aug 2007 12:20:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2007 12:20:34 +0000 (UTC) Cc: Carson Reynolds To: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 03 14:20:31 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IGw8t-0002R4-4Q for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Aug 2007 14:20:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGw8s-000891-He for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Aug 2007 08:20:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IGw8e-00085v-5w for bug-gnu-emacs@gnu.org; Fri, 03 Aug 2007 08:20:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IGw8Z-00085Z-3J for bug-gnu-emacs@gnu.org; Fri, 03 Aug 2007 08:20:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGw8Y-00085W-S3 for bug-gnu-emacs@gnu.org; Fri, 03 Aug 2007 08:20:10 -0400 Original-Received: from wx-out-0506.google.com ([66.249.82.227]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IGw8Y-0006pm-IC for bug-gnu-emacs@gnu.org; Fri, 03 Aug 2007 08:20:10 -0400 Original-Received: by wx-out-0506.google.com with SMTP id s7so695674wxc for ; Fri, 03 Aug 2007 05:20:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-type:message-id:cc:content-transfer-encoding:subject:date:to:x-mailer:from; b=cmdbS2Gb6qpT+lhoUOvrRa59xFzJo6cnsjIAkGli4yyWj4u3SWW3nUGr4njmSxtNbGDyJw8WeuCHYt8Q4VjRx4qy8P3KKq3agDvvNtYNVTCAvoTQzP/dQhBW3ilnUFcqZhM0PmJiWnVd5S/yczyS7IGGjvOFUEW5BRzxvDBGdT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:subject:date:to:x-mailer:from; b=RXSJel4QO4yTkezKMDfdk2EBjl/ppFZd7twA2OBnp+f85qqTLUVlEC/ULGZJrrJwrG2BLttsnK1Lif/a6K+RnFvAZVjv8xEHoGu5hjGRc+dlX001dkvy/50RTXV2H8HUFwroGZZY2k35Jud1RbViBzvDic/59krgxnsl3lU2PRY= Original-Received: by 10.70.117.3 with SMTP id p3mr5009809wxc.1186143608863; Fri, 03 Aug 2007 05:20:08 -0700 (PDT) Original-Received: from ?10.34.144.183? ( [12.153.11.140]) by mx.google.com with ESMTPS id i14sm2969291wxd.2007.08.03.05.20.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2007 05:20:08 -0700 (PDT) X-Mailer: Apple Mail (2.752.2) X-Detected-Kernel: Linux 2.6 (newer, 2) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16275 Archived-At: 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(# 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