On Sun, Oct 04, 2026 at 01:56:05PM +0200, Patrice Dumas wrote: > On Sun, Oct 04, 2026 at 09:59:33AM +0100, Gavin Smith wrote: > > On Sun, Oct 04, 2026 at 09:55:10AM +0200, Patrice Dumas wrote: > > > No, I am talking about input files. In the tests, there is a file with > > > a CRLF because there is an explicit CR at the end of the line. > > > tta/perl/t/input_files/only_special_spaces_node.texi > > > Currently, the CR is removed on Windows with text I/O, while > > > on GNU/Linux, the CR is left. This leads to a different tree (and > > > probably different output). > > > > That sounds like an acceptable difference, as if somebody is transferring > > text files with CRLF line endings from a Windows system, then they should > > convert the file. I don't understand why there is a problem if that is the > > current behaviour. > > No problem, except for differences in test results. If we remove a > trailing CR, we fix that difference. We also make it easy for people to > transfer text files between MS-Windows and GNU/Linux, which is right, > even if it is not a priority for us, something I agree with. > > > The initial email in the thread said there were test > > failures on MSYS2. I am not familiar with the details of every platform > > that runs on MS-Windows but is it possible that MSYS2 doesn't use CRLF line > > endings? > > The bulk of test failures are not about CRLF in input files, but about > CRLF in output files. On this, there is a consensus, though, so there > is no need to discuss further, I think, and this issue of CRLF in output > files and comparison with test results should be fixed in this commit: > > https://cgit.git.savannah.gnu.org/cgit/texinfo.git/commit/?id=956ed4855f2b8c8a5972ebb16496d08e202f34af
I see that, but is possible to add a comment somewhere to explain that this is for the benefit of MS-Windows? The concept of a "binary file" doesn't make much sense without this context. > In this case, it seems to me that TeX is clearly wrong. @<SPACE> should > definitively not become a @ followed by end of line in @def* lines. In > other contexts, it is still wrong, though less a problem, but on @def* > lines, the two are very different. It's a fundamental aspect of the TeX program as designed by the original author, Donald Knuth, so is not going to change. It is nothing to do with the texinfo.tex implementation in particular. It is not urgent to change texi2any to match texinfo.tex output if you feel strongly that the TeX behaviour is wrong. > In other contexts this still seems wrong to me, as @<SPACE> should be a > "protected" space and not a regular space that can be removed. > > > With texi2any, if the space is deleted from the end of the line, then the > > output looks like the following, which is consistent with the TeX output: > > Indeed, but in the @def* context, the @ followed by new line is not the > special spaces of @<SPACE> @<TAB> or @<NEWLINE>, but is is a > continuation character (that does not have an equivalent in the > remaining of the Texinfo language). > > > If we consistently removed spaces from the end of input lines (which I > > believe would cover \r, \f, \t and \v) then it would make the treatment > > of CRLF line endings consistent and also reduce the amount of possible > > inconsistency between texi2any and TeX processing. > > Maybe in other cases, but with @<SPACE> on @def* line, and more generally > with @<SPACE>, which means a "protected" space, this is wrong. It is also > wrong with @<TAB> and @<NEWLINE>. > > -- > Pat
