Subject: bug#1853 closed by Eli Zaretskii <[email-masked]> (Re: bug#1853: Trouble with gzipped info files on Windows)

From: [email-masked] (Emacs bug Tracking System)
Date: Sat, 17 Jan 2009 13:20:03 +0000

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 <[email-masked]>.

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 <[email-masked]> by
replying to this email.

-- 
1853: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1853
Emacs Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#1853: Trouble with gzipped info files on Windows
From: Eli Zaretskii <[email-masked]>
To: Juanma Barranquero <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Sat, 17 Jan 2009 15:11:14 +0200

> Date: Sat, 10 Jan 2009 22:49:05 +0100
> From: "Juanma Barranquero" <[email-masked]>
> 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.

Subject: Trouble with gzipped info files on Windows
From: "Juanma Barranquero" <[email-masked]>
To: "Emacs Bug Tracker" <[email-masked]>
Date: Sat, 10 Jan 2009 22:49:05 +0100

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"