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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lekktu <at> gmail.com, 14822 <at> debbugs.gnu.org
Subject: bug#14822: ^M in info files
Date: Sat, 13 Jul 2013 14:48:02 +0300

> Date: Sat, 13 Jul 2013 13:10:53 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, 14822 <at> 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,next-window
2571,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?

Previous Next

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