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: Juanma Barranquero <lekktu <at> gmail.com>
Subject: bug#14822: closed (Re: bug#14822: ^M in info files)
Date: Sat, 13 Jul 2013 10:34:03 +0000

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

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 14822 <at> debbugs.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: 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.

[Message part 3 (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.

Previous Next

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