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

[Vincent Belaïche]

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 

START-INFO-DIR-ENTRY

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

https://savannah.gnu.org/bugs/download.php?file_id=28919
https://savannah.gnu.org/bugs/download.php?file_id=28920

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

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

   Vincent.