On Sun, Oct 04, 2026 at 09:55:10AM +0200, Patrice Dumas wrote:
> On Sun, Oct 04, 2026 at 07:34:17AM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 3 Oct 2026 23:53:00 +0200
> > > From: Patrice Dumas <[email protected]>
> > >
> > > On Sat, Oct 03, 2026 at 10:38:01PM +0100, Gavin Smith wrote:
> > > > We don't need to support input files with CRLF line endings except
> > > > perhaps
> > > > on MS-Windows-like platforms, despite the certainty expressed in the
> > > > message
> > > > you are replying to. It's a unnecessary burden that we are free to
> > > > reject.
> > >
> > > I agree, but I do not think that it is wrong either, and to have the
> > > same output for tests on Windows and POSIX platform it would be handy.
> >
> > I don't think I understand your "but": Gavin was talking about input
> > files, whereas you seem to be talking about output.
>
> 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.
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? I read that it was based on Cygwin which uses (Unix-like) LF line
endings, as far as I am aware. However, as I understand MSYS2 is for building
software on Windows, and is not a general purpose computing environment, so
there may be nuances here that impact the issue.
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.
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.
> > Are you talking about input or output? On input, CR is removed
> > automatically if you open in (the default) text mode, so why
> > complicate things by opening input files in binary mode, in which case
> > our application code will need to deal with removing CR?
>
> Because of the case above of an explicit CR in at the end of line before
> a LF, which is not removed in GNU/Linux.
>
> > If you are talking about producing Unix-style LF-only output files,
>
> Output is ok, my understanding is that producing native newlines is ok,
> which is what we do, except for Info output file that we open in binary
> mode, as you say.
>
> > If we read input in binary mode, then indeed we need to remove CR "by
> > hand".
>
> We may not need to do it in general, but we need to do it if we want to
> have CRLF treated the same on GNU/Linux and Windows, by removing CR in
> both cases.
>
> We do not necessarily need to do it for every input file, for example we
> may not need to do that for CSS files or htmlxref files until we add a
> test file with CRLF, but my feeling is that it would be more robust and
> consistent if we did it for every input file.
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:
\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.
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:
This is trailing-whitespace.info, produced by texi2any version 7.3dev
from trailing-whitespace.texi.
-- Function: foo (bar,baz)
AAAAA
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.
