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 > If there are test differences in a small number of tests, this could be > fixed with better special casing by platform as to what results are expected. > I am sure we do this already with particular tests. As far as I can tell, we don't. What we do is that we skip some tests in some cases, but it is not ideal, because the regeneration of the test results is not done and there can be inconsistencies. > It's not our problem to make it easy for people to transfer text files > between MS-Windows and GNU/Linux or other Unix-like system, or to allow > people to use CRLF line endings on GNU/Linux. It becomes our problem if it helps with having tests easier to maintain. > As I said previously I'm interested in consistency with TeX, which is more > important. For example, consider following input, with <SPACE> replaced > by a single ASCII space: This is an interesting matter, but it should really be discussed separately from the issue of new lines. > \input texinfo > > @defun foo (bar,@<SPACE> > baz) > AAAAA > @end defun > > @bye > > texi2any produces the output: > > This is trailing-whitespace.info, produced by texi2any version 7.3dev > from trailing-whitespace.texi. > > -- Function: foo (bar, > baz) AAAAA > > (There is a space line after "bar," on the first line although it will > probably disappear from this email when I sent it.) > > The output with TeX/texinfo.tex looks like: > > foo (bar,baz) [Function] > > With TeX, the whitespace is deleted from the end of the line and so the > @ becomes a continuation character. 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. 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
