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

Previous Next

Packages: w32, emacs;

Reported by: "Juanma Barranquero" <lekktu <at> gmail.com>

Date: Sat, 10 Jan 2009 21:55:03 UTC

Severity: normal

Found in version 23.0.60

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Emacs Bug Tracker" <submit <at> debbugs.gnu.org>
Subject: bug#1853: 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"




This bug report was last modified 16 years and 180 days ago.

Previous Next


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