Subject: Re: bug#1853: Trouble with gzipped info files on Windows

From: Eli Zaretskii <[email-masked]>
Date: Mon, 19 Jan 2009 06:11:42 +0200

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked],  [email-masked]
> 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?