[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #38795] texi2any makes CR in output when input is mixed CR-LF a

From: Vincent Belaïche
Subject: Re: [bug #38795] texi2any makes CR in output when input is mixed CR-LF and LF files
Date: Sat, 24 Aug 2013 15:52:48 +0200
User-agent: Thunderbird (Windows/20100228)

Hello Karl,

Answers embedded below,

Karl Berry a écrit :
Hi Vincent,

I need to be able to reproduce the problem on my machine.  Sorry, but I
have no clue what to do with the Info files you uploaded.  Nor am I
going to be doing anything on MSYS or compiling any C++ wrappers.  BTW,
the files in your original bbdb.tgz did not contain any CR characters.

Anyway, I think I may have finally discovered the problem you've been
trying to report.  If I add CR characters to your bbdb.texi,
1) the START-INFO-DIR-ENTRY section text in the resulting .info has a ^M
   (even though nothing else in the output .info does), and

Well in the very bug #38795 case I did not have this problem:
- the bbdb.texi and other files have LF eol all over as you mentioned, but my texi2any output some info file with consistent CRLF ending for all the file. As we had already discussed whether info files have CRLF or LF eol should not matter on a MSW system, provided that the encoding is consistent. - I have tried what you say (convert bbdb.texi only to CRLF eol by some awk '{print $0 "\r"}' oneliner) but that did not change the resulting bbdb.info, it is still consistently encoded with CRLF all along - I have tried also over cr.texi, and I get the also a cr.info with consistent CRLF eols over the whole file.

I think that I had met the problem that you are mentionning (ie CRLF only for the

section) some time before, but I cannot reproduce it any longer --- maybe I should check my texi2any version.

Anyway, the real problem that I had met is that I thought that I had info files inconsistently encoded (i.e. mixed CRLF and LF), however as hard as I tried I could not reproduce it any longer. I am now even wondering whether this is really a Texinfo issue or some EMACS display artefact as what I had seen is no ^M endings at the beginning of the file, but some only at the end.

Anyway, I have some evidence that EMACS' way of displaying those files is a bit confusing, please look at the following two screen captures, the first one is the display of cr.info, and the second of bbdb.info


both info files are consistently encoded with CRLF eols which I checked in hexl-mode, and both files have some control characters, like ^_, but for cr.info the ^M are not displayed, while for bbdb.info they are displayed. Why so, it is a mystery to me.

What I am claiming with #38795 is that at some point of time I had a display of bbdb.info with the beginning of the file without ^M eol display (like in https://savannah.gnu.org/bugs/download.php?file_id=28919 picture) and the end of the file with the ^M eol display (like in https://savannah.gnu.org/bugs/download.php?file_id=28920 picture). I am really mad that I did not take any screen capture of that thing. That was because at the time I had no idea that the problem may ever be related to EMACS itself, and I was blaming texinfo.

2) install-info reacts badly to that ^M.

Yes, this is a problem that I had already met, and for which I had sent a patch I think. Good if you could make install-info CRLF-robust.

If the problem you're seeing is something different, please try to explain.

See above, as I cannot reproduce it, well, maybe we should give up. I have tried to convert BIG info files to CRLF eol's (by some awk one-liner) and then visit them with EMACS, but I could not reproduce the issue of mixed ^M/no ^M display, nor could I confirm whether that this is really an EMACS issue.

If you wish I can raise the question over the emacs-devel forum whether people think that such a display arte fact/inconsistency can exist.

Anyway, Patrice, can you look into 1),
I don't think that I have the latest perl code:

Locales dir for document strings not found
texi2any (GNU texinfo) 5.0+dev

Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I should retry with a checked out version.

Anyway, one question to Patrice is the following:
- is that acceptable that info files have CRLF eols, provided that this is consistent all over the file. Anyway recent EMACS info viewers handle well this situation
- or should texi2any ensure that it is always LF eols.
- please note that 4.13 version had the latter behaviour: whethere source code contains LF or CRLF eols, the output is always in LF endings.

My own/personal opinion is that info files should always have LF only eol for backward compatibility and disk space (let us save the planet ;-) ), but I am not bothering if there are CRLF provided that install-info does not bother either.
and I'll look into 2).
Small test file (with CRLF line endings) attached.


Thank you for the kind feedback, and have a nice day.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]