From unknown Mon Aug 18 19:27:40 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1853: Trouble with gzipped info files on Windows Reply-To: "Juanma Barranquero" , 1853@debbugs.gnu.org Resent-From: "Juanma Barranquero" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Sat, 10 Jan 2009 21:55:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: report 1853 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.123162415930983 (code B ref -1); Sat, 10 Jan 2009 21:55:03 +0000 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" 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 unknown Mon Aug 18 19:27:40 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) X-Loop: owner@emacsbugs.donarmstrong.com From: help-debbugs@gnu.org (Emacs bug Tracking System) To: "Juanma Barranquero" Subject: bug#1853 closed by Eli Zaretskii (Re: bug#1853: Trouble with gzipped info files on Windows) Message-ID: References: X-Emacs-PR-Message: they-closed 1853 X-Emacs-PR-Package: emacs,w32 Reply-To: 1853@debbugs.gnu.org Date: Sat, 17 Jan 2009 13:20:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1232198403-22577-1" This is a multi-part message in MIME format... ------------=_1232198403-22577-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is an automatic notification regarding your bug report which was filed against the emacs,w32 package: #1853: Trouble with gzipped info files on Windows It has been closed by Eli Zaretskii . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Eli Zaretskii by replying to this email. --=20 1853: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D1853 Emacs Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1232198403-22577-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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. ------------=_1232198403-22577-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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" ------------=_1232198403-22577-1-- From unknown Mon Aug 18 19:27:40 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1853: Trouble with gzipped info files on Windows Reply-To: Eli Zaretskii , 1853@debbugs.gnu.org Resent-From: Eli Zaretskii Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Sat, 17 Jan 2009 14:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1853 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Received: via spool by 1853-submit@emacsbugs.donarmstrong.com id=B1853.12322011462873 (code B ref 1853); Sat, 17 Jan 2009 14:15:02 +0000 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 In-reply-to: X-012-Sender: halo1@inter.net.il To: 1853@debbugs.gnu.org Cc: lekktu@gmail.com, emacs-devel@gnu.org 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 unknown Mon Aug 18 19:27:40 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1853: Trouble with gzipped info files on Windows Reply-To: Eli Zaretskii , 1853@debbugs.gnu.org Resent-From: Eli Zaretskii Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Sat, 17 Jan 2009 14:25:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1853 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Received: via spool by 1853-submit@emacsbugs.donarmstrong.com id=B1853.12322017225286 (code B ref 1853); Sat, 17 Jan 2009 14:25:05 +0000 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 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 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 unknown Mon Aug 18 19:27:40 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1853: Trouble with gzipped info files on Windows Reply-To: Stefan Monnier , 1853@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Sun, 18 Jan 2009 21:05:09 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1853 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Received: via spool by 1853-submit@emacsbugs.donarmstrong.com id=B1853.123231250913127 (code B ref 1853); Sun, 18 Jan 2009 21:05:09 +0000 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 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 unknown Mon Aug 18 19:27:40 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1853: Trouble with gzipped info files on Windows Reply-To: Eli Zaretskii , 1853@debbugs.gnu.org Resent-From: Eli Zaretskii Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Mon, 19 Jan 2009 04:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1853 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Received: via spool by 1853-submit@emacsbugs.donarmstrong.com id=B1853.123233830925278 (code B ref 1853); Mon, 19 Jan 2009 04:20:02 +0000 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 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 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 unknown Mon Aug 18 19:27:40 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1853: Trouble with gzipped info files on Windows Reply-To: Stefan Monnier , 1853@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Tue, 20 Jan 2009 05:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1853 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Received: via spool by 1853-submit@emacsbugs.donarmstrong.com id=B1853.123242821712391 (code B ref 1853); Tue, 20 Jan 2009 05:15:03 +0000 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 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 unknown Mon Aug 18 19:27:40 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1853: Trouble with gzipped info files on Windows Reply-To: Eli Zaretskii , 1853@debbugs.gnu.org Resent-From: Eli Zaretskii Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Sat, 24 Jan 2009 15:40:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1853 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Received: via spool by 1853-submit@emacsbugs.donarmstrong.com id=B1853.123281129224396 (code B ref 1853); Sat, 24 Jan 2009 15:40:03 +0000 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 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 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 unknown Mon Aug 18 19:27:40 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) X-Loop: owner@emacsbugs.donarmstrong.com From: help-debbugs@gnu.org (Emacs bug Tracking System) To: "Juanma Barranquero" Subject: bug#1853 closed by Eli Zaretskii (Re: bug#1853: Trouble with gzipped info files on Windows) Message-ID: References: X-Emacs-PR-Message: they-closed 1853 X-Emacs-PR-Package: emacs,w32 Reply-To: 1853@debbugs.gnu.org Date: Sat, 24 Jan 2009 15:45:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1232811904-26902-1" This is a multi-part message in MIME format... ------------=_1232811904-26902-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is an automatic notification regarding your bug report which was filed against the emacs,w32 package: #1853: Trouble with gzipped info files on Windows It has been closed by Eli Zaretskii . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Eli Zaretskii by replying to this email. --=20 1853: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D1853 Emacs Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1232811904-26902-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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. ------------=_1232811904-26902-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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" ------------=_1232811904-26902-1--