From lekktu@gmail.com Sat Jan 10 13:49:19 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 10 Jan 2009 21:49:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-5.9 required=4.0 tests=FOURLA,HAS_PACKAGE autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-bw0-f11.google.com (mail-bw0-f11.google.com [209.85.218.11]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0ALnBY9030977 for ; Sat, 10 Jan 2009 13:49:13 -0800 Received: by bwz4 with SMTP id 4so2858959bwz.1 for ; Sat, 10 Jan 2009 13:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=hpolpFwSmsLTS2DHYs3SiazVV844nernXo/HjxDsKzc=; b=Ps4m5giN4+jZblZbJhf5wFx9gDW3fo77Ktj6ss5HG/cDS0kf3jNEMol1kagg1R3Eg+ khqV+r1dGeOFImCitpVPgT5mk1CDkJWiTU5kAfElNyuYptTTA7gB+bUU69EaPVnTfTjB wwM9xsYRqvIclLGuhZH/8kPOhce3/B3OW4vDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=bSEy0camCkJnFDw3PfxRnVP4jFhYW3FxJSCJlqaHg4sGgpjd+5Q55xy21z4v7ZFdyg 8aI+hmtJ0fs7hHUqU5EeT45c+tNBz0CcrYWal+Rtp0zozrUEVStVjd3Ly0bGMQrMNVk5 5e5VqwCHvUcblFjBtlxqmwirplHZq5zL5+wpk= Received: by 10.223.110.144 with SMTP id n16mr19757999fap.55.1231624145723; Sat, 10 Jan 2009 13:49:05 -0800 (PST) Received: by 10.223.115.79 with HTTP; Sat, 10 Jan 2009 13:49:05 -0800 (PST) Message-ID: Date: Sat, 10 Jan 2009 22:49:05 +0100 From: "Juanma Barranquero" To: "Emacs Bug Tracker" Subject: Trouble with gzipped info files on Windows MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Package: emacs,w32 Version: 23.0.60 Gzipping normal CRLF info files on Windows, there's currently two problems: 1.- For all info files: cd info gzip efaq emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info \"(efaq)\")" The info pages are decoded with a -unix coding system, so lines contain spurious ^M characters. It does depend on setting the language environment (on the command line or .emacs). For example, with my default "Spanish" environment, it does not happen; but if I pass "Spanish" in the command above, the info pages are erroneously decoded as info-latin-1-unix. The presence of NUL characters (see fixed bug#876) is irrelevant. efaq does contain NUL, but the same bug happens with gnus, which does not. 2.- Additionally, for info nodes that do NOT contain a Top node: cd info emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info \"(ccmode)\")" ;; works OK. gzip ccmode* emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info \"(ccmode)\")" ;; "No such node or anchor: Top" From eliz@gnu.org Sat Jan 17 05:11:52 2009 Received: (at 1853-done) by emacsbugs.donarmstrong.com; 17 Jan 2009 13:11:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0HDBm8a021324 for <1853-done@emacsbugs.donarmstrong.com>; Sat, 17 Jan 2009 05:11:49 -0800 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KDM002009XX1500@i-mtaout6.012.net.il> for 1853-done@emacsbugs.donarmstrong.com; Sat, 17 Jan 2009 15:11:25 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.42.36]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KDM007509YY1D50@i-mtaout6.012.net.il>; Sat, 17 Jan 2009 15:11:23 +0200 (IST) Date: Sat, 17 Jan 2009 15:11:14 +0200 From: Eli Zaretskii Subject: Re: bug#1853: Trouble with gzipped info files on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Juanma Barranquero , 1853-done@debbugs.gnu.org Cc: emacs-devel@gnu.org Reply-to: Eli Zaretskii Message-id: References: > Date: Sat, 10 Jan 2009 22:49:05 +0100 > From: "Juanma Barranquero" > Cc: > > Gzipping normal CRLF info files on Windows, there's currently two problems: > > 1.- For all info files: > > cd info > gzip efaq > emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info \"(efaq)\"))" > > The info pages are decoded with a -unix coding system, so lines > contain spurious ^M characters. > > It does depend on setting the language environment (on the command > line or .emacs). For example, with my default "Spanish" environment, > it does not happen; but if I pass "Spanish" in the command above, the > info pages are erroneously decoded as info-latin-1-unix. This happened because, on DOS and Windows, file-coding-system-alist includes the association `("" . find-buffer-file-type-coding-system)', and find-buffer-file-type-coding-system was not ready to see an argument whose `car' does not appear to exist because jka-compr removed the .gz extension from its name. I fixed find-buffer-file-type-coding-system to work correctly in this case. > 2.- Additionally, for info nodes that do NOT contain a Top node: > > cd info > emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info > \"(ccmode)\")" > ;; works OK. > > gzip ccmode* > emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info > \"(ccmode)\")" > ;; "No such node or anchor: Top" This is yet another separate bug: set-language-environment always sets default-buffer-file-coding-system to *-unix. See my other message a few minutes ago. From eliz@gnu.org Sat Jan 17 06:05:46 2009 Received: (at 1853) by emacsbugs.donarmstrong.com; 17 Jan 2009 14:05:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0HE5gIK002867 for <1853@emacsbugs.donarmstrong.com>; Sat, 17 Jan 2009 06:05:44 -0800 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KDM00800C5X6E00@i_mtaout2.012.net.il> for 1853@emacsbugs.donarmstrong.com; Sat, 17 Jan 2009 16:05:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.42.36]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KDM00IT4CHLHB81@i_mtaout2.012.net.il>; Sat, 17 Jan 2009 16:05:46 +0200 (IST) Date: Sat, 17 Jan 2009 16:05:36 +0200 From: Eli Zaretskii Subject: Re: bug#1853: Trouble with gzipped info files on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: 1853@debbugs.gnu.org Cc: lekktu@gmail.com, emacs-devel@gnu.org Reply-to: Eli Zaretskii Message-id: References: > Date: Sat, 17 Jan 2009 15:11:14 +0200 > From: Eli Zaretskii > Cc: emacs-devel@gnu.org > > This happened because, on DOS and Windows, file-coding-system-alist > includes the association `("" . find-buffer-file-type-coding-system)', > and find-buffer-file-type-coding-system was not ready to see an > argument whose `car' does not appear to exist because jka-compr > removed the .gz extension from its name. Actually, this explains why _visiting_ compressed files might produce a buffer with ^M characters in it. The change I made cannot help with Info files because the buffer name is "*info*" in that case, not FOO.gz. After the change, visiting, e.g., emacs-1.gz produces a buffer whose buffer-file-coding-system is -dos, and there are no ^M characters in it. Visiting ccmode-1.gz still produces ^M's (because ccmode-1 includes null characters in the Index node). > > 2.- Additionally, for info nodes that do NOT contain a Top node: > > > > cd info > > emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info > > \"(ccmode)\")" > > ;; works OK. > > > > gzip ccmode* > > emacs -Q --eval "(progn (set-language-environment \"UTF-8\") (info > > \"(ccmode)\")" > > ;; "No such node or anchor: Top" > > This is yet another separate bug: set-language-environment always sets > default-buffer-file-coding-system to *-unix. See my other message a > few minutes ago. Specifically, I propose the change below for this latter problem. After that change, visiting compressed files, both regular and Info files, work correctly for me, both before or after setting a non-default language environment. Index: lisp/international/mule-cmds.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/international/mule-cmds.el,v retrieving revision 1.353 diff -u -r1.353 mule-cmds.el --- lisp/international/mule-cmds.el 9 Jan 2009 05:01:02 -0000 1.353 +++ lisp/international/mule-cmds.el 17 Jan 2009 14:01:33 -0000 @@ -1936,7 +1936,11 @@ (eol-type (coding-system-eol-type default-buffer-file-coding-system))) (when priority (set-default-coding-systems - (if (memq eol-type '(0 1 2 unix dos mac)) + ;; Don't use eol-type if default-buffer-file-coding-system is + ;; nil, because coding-system-eol-type treats nil as + ;; `no-conversion'. + (if (and default-buffer-file-coding-system + (memq eol-type '(0 1 2 unix dos mac))) (coding-system-change-eol-conversion default-coding eol-type) default-coding)) (setq default-sendmail-coding-system default-coding) From eliz@gnu.org Sat Jan 17 06:15:22 2009 Received: (at 1853) by emacsbugs.donarmstrong.com; 17 Jan 2009 14:15:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0HEFIAS005022 for <1853@emacsbugs.donarmstrong.com>; Sat, 17 Jan 2009 06:15:19 -0800 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KDM00200CJ3LC00@i-mtaout6.012.net.il> for 1853@emacsbugs.donarmstrong.com; Sat, 17 Jan 2009 16:15:24 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.42.36]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KDM00J77CXMN430@i-mtaout6.012.net.il>; Sat, 17 Jan 2009 16:15:24 +0200 (IST) Date: Sat, 17 Jan 2009 16:15:14 +0200 From: Eli Zaretskii Subject: Re: bug#1853: Trouble with gzipped info files on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: 1853@debbugs.gnu.org, handa@m17n.org Cc: lekktu@gmail.com, emacs-devel@gnu.org Reply-to: Eli Zaretskii Message-id: References: > Date: Sat, 17 Jan 2009 16:05:36 +0200 > From: Eli Zaretskii > Cc: lekktu@gmail.com, emacs-devel@gnu.org > > --- lisp/international/mule-cmds.el 9 Jan 2009 05:01:02 -0000 1.353 > +++ lisp/international/mule-cmds.el 17 Jan 2009 14:01:33 -0000 > @@ -1936,7 +1936,11 @@ > (eol-type (coding-system-eol-type default-buffer-file-coding-system))) > (when priority > (set-default-coding-systems > - (if (memq eol-type '(0 1 2 unix dos mac)) > + ;; Don't use eol-type if default-buffer-file-coding-system is > + ;; nil, because coding-system-eol-type treats nil as > + ;; `no-conversion'. > + (if (and default-buffer-file-coding-system > + (memq eol-type '(0 1 2 unix dos mac))) > (coding-system-change-eol-conversion default-coding eol-type) > default-coding)) > (setq default-sendmail-coding-system default-coding) Upon further thought, perhaps we want the default coding-systems to have an explicit -dos EOL type on DOS and Windows, for consistency with how we set up things on startup. This would involve explicitly changing eol-type of default-coding before the last line above. WDYT? From monnier@iro.umontreal.ca Sun Jan 18 13:01:49 2009 Received: (at 1853) by emacsbugs.donarmstrong.com; 18 Jan 2009 21:01:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0IL1kLa013115 for <1853@emacsbugs.donarmstrong.com>; Sun, 18 Jan 2009 13:01:48 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EAFsnc0lMCpxj/2dsb2JhbACBbM1NhXOCAw X-IronPort-AV: E=Sophos;i="4.37,285,1231131600"; d="scan'208";a="32482782" Received: from 76-10-156-99.dsl.teksavvy.com (HELO ceviche.home) ([76.10.156.99]) by ironport2-out.teksavvy.com with ESMTP; 18 Jan 2009 16:01:41 -0500 Received: by ceviche.home (Postfix, from userid 20848) id EEFA6B40F2; Sun, 18 Jan 2009 16:01:40 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Cc: 1853@debbugs.gnu.org, handa@m17n.org, lekktu@gmail.com, emacs-devel@gnu.org Subject: Re: bug#1853: Trouble with gzipped info files on Windows Message-ID: References: Date: Sun, 18 Jan 2009 16:01:40 -0500 In-Reply-To: (Eli Zaretskii's message of "Sat, 17 Jan 2009 16:15:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Upon further thought, perhaps we want the default coding-systems to > have an explicit -dos EOL type on DOS and Windows, for consistency > with how we set up things on startup. This would involve explicitly > changing eol-type of default-coding before the last line above. Ideally, it should not only do the same as done on startup, but also do it by running the same code. Stefan From eliz@gnu.org Sun Jan 18 20:11:49 2009 Received: (at 1853) by emacsbugs.donarmstrong.com; 19 Jan 2009 04:11:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER, MONOTONE_WORDS_2_15 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0J4BjSg025272 for <1853@emacsbugs.donarmstrong.com>; Sun, 18 Jan 2009 20:11:47 -0800 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KDP008009R7SJ00@i-mtaout6.012.net.il> for 1853@emacsbugs.donarmstrong.com; Mon, 19 Jan 2009 06:11:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.131.96]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KDP005CDABPCMA0@i-mtaout6.012.net.il>; Mon, 19 Jan 2009 06:11:51 +0200 (IST) Date: Mon, 19 Jan 2009 06:11:42 +0200 From: Eli Zaretskii Subject: Re: bug#1853: Trouble with gzipped info files on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Cc: 1853@debbugs.gnu.org, handa@m17n.org, lekktu@gmail.com, emacs-devel@gnu.org Reply-to: Eli Zaretskii Message-id: References: > From: Stefan Monnier > Cc: 1853@emacsbugs.donarmstrong.com, handa@m17n.org, lekktu@gmail.com, emacs-devel@gnu.org > Date: Sun, 18 Jan 2009 16:01:40 -0500 > > > Upon further thought, perhaps we want the default coding-systems to > > have an explicit -dos EOL type on DOS and Windows, for consistency > > with how we set up things on startup. This would involve explicitly > > changing eol-type of default-coding before the last line above. > > Ideally, it should not only do the same as done on startup, but also do > it by running the same code. Right, I had that in mind, too. The problem is, it's not trivial. The way it works on startup now is a bit kludgey: dos-w32.el says (setq-default buffer-file-coding-system 'undecided-dos) and then set-language-environment-coding-systems does (let* ((priority (get-language-info language-name 'coding-priority)) (default-coding (car priority)) (eol-type (coding-system-eol-type default-buffer-file-coding-system))) ... (if (memq eol-type '(0 1 2 unix dos mac)) (coding-system-change-eol-conversion default-coding eol-type))) the kludge being that this only works because of the specific order files are loaded at dump time and the order of function invocation during startup. Are we okay with making non-trivial changes in that at this time? From lekktu@gmail.com Mon Jan 19 18:13:27 2009 Received: (at control) by emacsbugs.donarmstrong.com; 20 Jan 2009 02:13:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: ** X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=2.3 required=4.0 tests=MISSING_SUBJECT,NOSUBJECT, VALID_BTS_CONTROL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-bw0-f11.google.com (mail-bw0-f11.google.com [209.85.218.11]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0K2DKZA031692 for ; Mon, 19 Jan 2009 18:13:21 -0800 Received: by bwz4 with SMTP id 4so5629035bwz.1 for ; Mon, 19 Jan 2009 18:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=dB9xrQ/ahw9DnOltgJ+Ld/lMVgUZtKjWqkjqxjcBRw0=; b=XaUiuMrAOy31Q0Mfa0aEH33IDeVsi9mTvxvJqc8rFIBT8524extaI4UbZGQLk5FeOL i1lpTVbx8tfEjhLIhrpf+CT5crUrlgszdEkuzRudumWrjLTuAewYRt9b6pXbFVX9H7/9 1e8KRnpcu74t1KEqvd0K/tQf48k3IhbjSL0Gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=N3YRT7+w3W0LnHJoB0b1vk5X8DzUSKPWHhfDUVP0riwLkIli2Ft9Sa/oFVfaVL6K9g TDYqEBjr3E5rcMVwBlUzk+ip+hZXIPHBdnDXYzzJe0NlqREosn59GUTCmQ+kbEvOqDkl mPHZl4MkNbx4U/SgHB8j6ghGnlCknk2GbRdgs= MIME-Version: 1.0 Received: by 10.223.126.69 with SMTP id b5mr3388951fas.54.1232417593899; Mon, 19 Jan 2009 18:13:13 -0800 (PST) Date: Tue, 20 Jan 2009 03:13:13 +0100 Message-ID: Subject: From: Juanma Barranquero To: control@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit reopen 1853 quit From monnier@IRO.UMontreal.CA Mon Jan 19 21:10:17 2009 Received: (at 1853) by emacsbugs.donarmstrong.com; 20 Jan 2009 05:10:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pruche.dit.umontreal.ca (pruche.dit.umontreal.ca [132.204.246.22]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0K5A7bv011910 for <1853@emacsbugs.donarmstrong.com>; Mon, 19 Jan 2009 21:10:08 -0800 Received: from alfajor.home (vpn-132-204-232-174.acd.umontreal.ca [132.204.232.174]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n0K5AixS004272; Tue, 20 Jan 2009 00:10:45 -0500 Received: by alfajor.home (Postfix, from userid 20848) id 7E7301C167; Tue, 20 Jan 2009 00:10:04 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Cc: 1853@debbugs.gnu.org, handa@m17n.org, lekktu@gmail.com, emacs-devel@gnu.org Subject: Re: bug#1853: Trouble with gzipped info files on Windows Message-ID: References: Date: Tue, 20 Jan 2009 00:10:04 -0500 In-Reply-To: (Eli Zaretskii's message of "Mon, 19 Jan 2009 06:11:42 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3192=0 > the kludge being that this only works because of the specific order > files are loaded at dump time and the order of function invocation > during startup. Are we okay with making non-trivial changes in that > at this time? I guess it's better to make a simpler local change, and add a big fat comment about what should be done instead. Stefan From eliz@gnu.org Sat Jan 24 07:34:52 2009 Received: (at 1853) by emacsbugs.donarmstrong.com; 24 Jan 2009 15:34:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0OFYmXW024390 for <1853@emacsbugs.donarmstrong.com>; Sat, 24 Jan 2009 07:34:49 -0800 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KDZ00M00ECIK500@i-mtaout6.012.net.il> for 1853@emacsbugs.donarmstrong.com; Sat, 24 Jan 2009 17:34:57 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.6.113]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KDZ003DTFA7IMH0@i-mtaout6.012.net.il>; Sat, 24 Jan 2009 17:34:57 +0200 (IST) Date: Sat, 24 Jan 2009 17:34:42 +0200 From: Eli Zaretskii Subject: Re: bug#1853: Trouble with gzipped info files on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Cc: 1853@debbugs.gnu.org, handa@m17n.org, lekktu@gmail.com, emacs-devel@gnu.org Reply-to: Eli Zaretskii Message-id: References: > From: Stefan Monnier > Cc: 1853@emacsbugs.donarmstrong.com, handa@m17n.org, lekktu@gmail.com, > emacs-devel@gnu.org > Date: Tue, 20 Jan 2009 00:10:04 -0500 > > > the kludge being that this only works because of the specific order > > files are loaded at dump time and the order of function invocation > > during startup. Are we okay with making non-trivial changes in that > > at this time? > > I guess it's better to make a simpler local change, and add a big fat > comment about what should be done instead. Done, with the following change: Index: lisp/international/mule-cmds.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/international/mule-cmds.el,v retrieving revision 1.353 retrieving revision 1.354 diff -u -r1.353 -r1.354 --- lisp/international/mule-cmds.el 9 Jan 2009 05:01:02 -0000 1.353 +++ lisp/international/mule-cmds.el 24 Jan 2009 15:31:09 -0000 1.354 @@ -1933,7 +1933,25 @@ "Do various coding system setups for language environment LANGUAGE-NAME." (let* ((priority (get-language-info language-name 'coding-priority)) (default-coding (car priority)) - (eol-type (coding-system-eol-type default-buffer-file-coding-system))) + ;; If default-buffer-file-coding-system is nil, don't use + ;; coding-system-eol-type, because it treats nil as + ;; `no-conversion'. default-buffer-file-coding-system is set + ;; to nil by reset-language-environment, and in that case we + ;; want to have here the native EOL type for each platform. + ;; FIXME: there should be a common code that runs both on + ;; startup and here to set the default EOL type correctly. + ;; Right now, DOS/Windows platforms set this on dos-w32.el, + ;; which works only as long as the order of loading files at + ;; dump time and calling functions at startup is not modified + ;; significantly, i.e. as long as this function is called + ;; _after_ default-buffer-file-coding-system was set by + ;; dos-w32.el. + (eol-type + (if (null default-buffer-file-coding-system) + (cond ((memq system-type '(windows-nt ms-dos)) 1) + ((eq system-type 'macos) 2) + (t 0)) + (coding-system-eol-type default-buffer-file-coding-system)))) (when priority (set-default-coding-systems (if (memq eol-type '(0 1 2 unix dos mac)) From eliz@gnu.org Sat Jan 24 07:39:54 2009 Received: (at 1853-done) by emacsbugs.donarmstrong.com; 24 Jan 2009 15:39:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout5.012.net.il (mtaout5.012.net.il [84.95.2.13]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0OFdopT025605 for <1853-done@emacsbugs.donarmstrong.com>; Sat, 24 Jan 2009 07:39:52 -0800 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KDZ00600F6ZA900@i_mtaout5.012.net.il> for 1853-done@emacsbugs.donarmstrong.com; Sat, 24 Jan 2009 17:39:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.6.113]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KDZ00442FICFGI0@i_mtaout5.012.net.il> for 1853-done@emacsbugs.donarmstrong.com; Sat, 24 Jan 2009 17:39:49 +0200 (IST) Date: Sat, 24 Jan 2009 17:39:35 +0200 From: Eli Zaretskii Subject: Re: bug#1853: Trouble with gzipped info files on Windows X-012-Sender: halo1@inter.net.il To: 1853-done@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: Fixed with the change in my latest message on this subject. From unknown Mon Aug 18 00:08:28 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Sun, 22 Feb 2009 15:24:05 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator