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

Previous Next

Full log

View this message in rfc822 format

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: bug#1853: Trouble with gzipped info files on Windows
Date: Mon, 19 Jan 2009 06:11: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: 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?

Previous Next

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