bug#1853: marked as done (Trouble with gzipped info files on Windows)

[Emacs bug Tracking System]

Your message dated Sat, 17 Jan 2009 15:11:14 +0200
with message-id <utz7y2i31.fsf@gnu.org>
and subject line Re: bug#1853: Trouble with gzipped info files on Windows
has caused the Emacs bug report #1853,
regarding Trouble with gzipped info files on Windows
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1853: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1853
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Trouble with gzipped info files on Windows
>
>
>
>
> 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"
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#1853: Trouble with gzipped info files on Windows
>
>
>
>
> Date: 
>
> Sat, 17 Jan 2009 15:11:14 +0200
>
>
>
>
> > Date: Sat, 10 Jan 2009 22:49:05 +0100
> > From: "Juanma Barranquero" <lekktu@gmail.com>
> > 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.
>
>
> --- End Message ---