GNU bug report logs - #14822
^M in info files

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#14822: closed (^M in info files)
Date: Sat, 13 Jul 2013 10:34:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 13 Jul 2013 13:32:52 +0300
with message-id <83wqou4unf.fsf <at> gnu.org>
and subject line Re: bug#14822: ^M in info files
has caused the debbugs.gnu.org bug report #14822,
regarding ^M in info files
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
14822: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14822
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: ^M in info files
Date: Mon, 8 Jul 2013 18:35:54 +0200

Package: emacs
Version: 24.3.50


Visiting most info topics (Ada Mode, Emacs Lisp Intro, CC Mode...) on
Windows gives info buffers detected as Unix-style and with lines
ending in ^M. Some other topics (Emacs, Emacs Lisp, Gnus) work as
expected.

All info files (in both groups) have CRLF endings, were generated with
the same tool and appear to be correct.

This is a Windows issue, though there hasn't been any Windows-specific
coding-related change lately, so it's likely caused by some generic
change.

The problem does not happen on 24.3, only trunk.

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14822-done <at> debbugs.gnu.org
Subject: Re: bug#14822: ^M in info files
Date: Sat, 13 Jul 2013 13:32:52 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 8 Jul 2013 18:35:54 +0200
> 
> Visiting most info topics (Ada Mode, Emacs Lisp Intro, CC Mode...) on
> Windows gives info buffers detected as Unix-style and with lines
> ending in ^M. Some other topics (Emacs, Emacs Lisp, Gnus) work as
> expected.
> 
> All info files (in both groups) have CRLF endings, were generated with
> the same tool and appear to be correct.
> 
> This is a Windows issue, though there hasn't been any Windows-specific
> coding-related change lately, so it's likely caused by some generic
> change.

This was not a Windows-specific issue: we were ignoring the
inhibit-null-byte-detection flag when decoding, because the machinery
that implements that flag has changed.

Should be fixed in trunk revision 113413.

Previous Next

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