GNU bug report logs - #1853
Trouble with gzipped info files on Windows

Previous Next

Packages: w32, emacs;

Reported by: "Juanma Barranquero" <lekktu <at> gmail.com>

Date: Sat, 10 Jan 2009 21:55:03 UTC

Severity: normal

Found in version 23.0.60

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #42 received at 1853 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 1853 <at> debbugs.gnu.org, handa <at> m17n.org, lekktu <at> gmail.com,
        emacs-devel <at> gnu.org
Subject: Re: bug#1853: Trouble with gzipped info files on Windows
Date: Sat, 24 Jan 2009 17:34:42 +0200
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: 1853 <at> emacsbugs.donarmstrong.com, handa <at> m17n.org, lekktu <at> gmail.com,
>         emacs-devel <at> 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))




This bug report was last modified 16 years and 180 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.