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

[Eli Zaretskii]

> Date: Sat, 10 Jan 2009 22:49:05 +0100
> From: "Juanma Barranquero" <address@hidden>
> 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.