Subject: bug#14822: closed (Re: bug#14822: ^M in info files)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 13 Jul 2013 10:34:03 +0000

Your bug report

#14822: ^M in info files

which was filed against the emacs,w32 package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

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

Subject: Re: bug#14822: ^M in info files
From: Eli Zaretskii <[email-masked]>
To: Juanma Barranquero <[email-masked]>
Cc: [email-masked]
Date: Sat, 13 Jul 2013 13:32:52 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Juanma Barranquero <[email-masked]>
> 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.

Subject: ^M in info files
From: Juanma Barranquero <[email-masked]>
To: Bug-Gnu-Emacs <[email-masked]>
Date: Mon, 8 Jul 2013 18:35:54 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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.