[debbugs-tracker] bug#14822: closed (^M in info files)

[GNU bug Tracking System]

Your message dated Sat, 13 Jul 2013 13:32:52 +0300
with message-id <address@hidden>
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
address@hidden)


-- 
14822: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14822
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> 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.
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#14822: ^M in info files
>
>
>
>
> Date: 
>
> Sat, 13 Jul 2013 13:32:52 +0300
>
>
>
>
> > From: Juanma Barranquero <address@hidden>
> > 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.
>
>
> --- End Message ---