GNU bug report logs -
#1853
Trouble with gzipped info files on Windows
Previous Next
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
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.