bug#14822: ^M in info files

bug#14822: ^M in info files

[Juanma Barranquero]

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.

bug#14822: ^M in info files

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> All info files (in both groups) have CRLF endings,

All lines?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#14822: ^M in info files

[Juanma Barranquero]

On Mon, Jul 8, 2013 at 6:52 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:

> All lines?

Didn't check exhaustively, but AFAICS, yes. I mean, it's not a stray
^M here and there, but apparently the full info buffer(s) all the way
to the end.

bug#14822: ^M in info files

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 8 Jul 2013 18:56:37 +0200
> Cc: 14822@debbugs.gnu.org
> 
> On Mon, Jul 8, 2013 at 6:52 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> > All lines?
> 
> Didn't check exhaustively

I did.  Yes, all of them.

I think those files that display correctly have a coding: cookie.

bug#14822: ^M in info files

[Juanma Barranquero]

On Mon, Jul 8, 2013 at 7:09 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I think those files that display correctly have a coding: cookie.

I though so initially, but some files (like ert.info and edt.info) do
not have a coding: cookie and yet are displayed correctly.

bug#14822: ^M in info files

[martin rudalics]

 > 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.

Ever since this happens etags has stopped to work on routines written in
C here.  I get something like that it couldn't find an identifier with a
^M prepended to the symbol not being found.

Since building the trunk is currently broken here, I can't send the
precise message though.

martin

bug#14822: ^M in info files

[Eli Zaretskii]

> Date: Tue, 09 Jul 2013 11:08:26 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 14822@debbugs.gnu.org
> 
> Ever since this happens etags has stopped to work on routines written in
> C here.  I get something like that it couldn't find an identifier with a
> ^M prepended to the symbol not being found.

I cannot reproduce this with etags.  You seem to be saying that the
TAGS files have DOS-style CRLF EOL format.  But I cannot see how this
is possible, since etags.c forces all I/O to be in binary mode.  Are
you using some other program for creating the tags tables, perhaps?

bug#14822: ^M in info files

[martin rudalics]

 >> Ever since this happens etags has stopped to work on routines written in
 >> C here.  I get something like that it couldn't find an identifier with a
 >> ^M prepended to the symbol not being found.
 >
 > I cannot reproduce this with etags.  You seem to be saying that the
 > TAGS files have DOS-style CRLF EOL format.

No (that is, I'm 99% sure they didn't).

 > But I cannot see how this
 > is possible, since etags.c forces all I/O to be in binary mode.  Are
 > you using some other program for creating the tags tables, perhaps?

I'm using etags.  Unfortunately, I cannot tell what etags produced since
I don't have the tags tables around anymore and am currently not able to
build new ones.  IIRC what happend was that looking up an Elisp routine
failed because some strange characters got prepended to the identifiers
corresponding to Elisp functions.  So I was informed that looking up
^MFnext_window (or so, followed by an extra newline in the minibuffer)
failed.  And I even forgot whether the tags tables contained
Fnext_window at all.  Earlier tags tables contained lines like:

DEFUN ("next-window", Fnext_window,\x7fnext-window\x012571,85206

so looking for Fnext_window prepended with something like "^M" doesn't
seem right to me.

Problems started about the same time ^Ms appeared in info lines.  But
maybe it's completely unrelated.  I'll tell you more as soon as I'm able
to build again.

martin

bug#14822: ^M in info files

[Eli Zaretskii]

> Date: Sat, 13 Jul 2013 13:10:53 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, 14822@debbugs.gnu.org
> 
>  >> Ever since this happens etags has stopped to work on routines written in
>  >> C here.  I get something like that it couldn't find an identifier with a
>  >> ^M prepended to the symbol not being found.
>  >
>  > I cannot reproduce this with etags.  You seem to be saying that the
>  > TAGS files have DOS-style CRLF EOL format.
> 
> No (that is, I'm 99% sure they didn't).

Then where could the ^M characters come from?  Whatever our bugs
regarding EOL decoding do, they don't _invent_ ^M characters.

> IIRC what happend was that looking up an Elisp routine
> failed because some strange characters got prepended to the identifiers
> corresponding to Elisp functions.  So I was informed that looking up
> ^MFnext_window (or so, followed by an extra newline in the minibuffer)
> failed.

Strange.

> And I even forgot whether the tags tables contained
> Fnext_window at all.  Earlier tags tables contained lines like:
> 
> DEFUN ("next-window", Fnext_window,\x7fnext-window\x012571,85206

They still do.

> Problems started about the same time ^Ms appeared in info lines.  But
> maybe it's completely unrelated.

It it's related, it should be solved now.

What problems do you have to build Emacs?  Did you install autoconf
and automake from my site?

bug#14822: ^M in info files

[martin rudalics]

 > What problems do you have to build Emacs?  Did you install autoconf
 > and automake from my site?

Yes.  Juanma patiently provided answers to most of my questions but I
haven't adapted my (slighly idiosyncratic) build environment yet.  Among
others I want to build in the source tree but am afraid to crowd my src
directories with object files.  Juanma told me that if I want to build
in-place there's no way to get back the old separate (oo) directories.

martin

bug#14822: ^M in info files

[Eli Zaretskii]

> Date: Sat, 13 Jul 2013 15:56:25 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, 14822@debbugs.gnu.org
> 
> Juanma told me that if I want to build in-place there's no way to
> get back the old separate (oo) directories.

That's true, but why do you need the separate oo directories?

FWIW, I build in-place all the time, and never had any trouble with
that.  If I need the old configure.bat build, I use a separate local
branch.

bug#14822: ^M in info files

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@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.

bug#14822: ^M in info files

[Juanma Barranquero]

On Sat, Jul 13, 2013 at 12:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> This was not a Windows-specific issue

I meant the symptom that triggered the report: spurious ^M in info
files aren't likely to appear in non-Windows builds.

> Should be fixed in trunk revision 113413.

Thanks.

bug#14822: ^M in info files

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 15 Jul 2013 13:46:29 +0200
> Cc: 14822@debbugs.gnu.org
> 
> On Sat, Jul 13, 2013 at 12:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > This was not a Windows-specific issue
> 
> I meant the symptom that triggered the report: spurious ^M in info
> files aren't likely to appear in non-Windows builds.

They would, in any DOS-style file.

bug#14822: ^M in info files

[Juanma Barranquero]

On Mon, Jul 15, 2013 at 5:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> They would, in any DOS-style file.

Yes. That's why I said "info files". Non-Windows (or MS-DOS port, I
suppose) info files do not have CRLF. Of course the bug you fixed
would be noticeable with some CRLF files.