Re: etags test is broken on MS-Windows

[Eli Zaretskii]

[Sorry, I didn't mean to discuss this in private, I just forgot to CC
the list.  Adding it now, and repeating my original message.]

I wrote:

> > Commit e0117b1 changed the new etags test suite in a way that makes it
> > always be skipped on MS-Windows (and in general on any platform that
> > doesn't have the 'locale' command or doesn't have a UTF-8 locale
> > installed).
> > 
> > I don't understand why a test suite needs to use UTF-8, but I don't
> > really mind as long as the tests can run on all supported platforms.
> > Can we fix the test to not require these features, please?

And Paul answered:

> Date: Mon, 18 May 2015 18:14:10 -0700
> From: Paul Eggert <address@hidden>
> 
> > I don't
> > really mind as long as the tests can run on all supported platforms.
> 
> Without that patch, the tests failed on my GNU/Linux host due to encoding 
> problems.  See attached file

I don't think it's due to encoding problem.  (AFAIK, etags doesn't
regard its input as characters, but as a stream of bytes.)

I think it's due to DOS CR-LF EOL format of some files in the test
suite.  For example, the first file whose tags were different in your
testing is dostorture.c, which has DOS EOLs, the second file, c.C, has
a lone ^M character at the end of one of its lines, and so on.

Could you please verify that this is indeed the source of the problem?

(There's also an unrelated problem with the gzip-compressed file in
f-src, which seems to be some Windows-specific glitch; I will look
into it separately.)

> > Can we fix the test to not require these features, please?
> 
> I don't know what will work on MS-Windows, but I checked in a stab
> at it.

Thanks, it works now, but I have the same problems due to EOL format,
and in the same files, just in reverse.

If we agree that the problem is due to EOL format, we could try
thinking about a solution.  The root cause for the problem is that on
Windows, etags accounts for the stripped CR characters, while on Unix
it treats them as part of the contents, so the byte counts are offset
by the number of the preceding lines.

> If this fails, I suggest removing all the non-ASCII characters from
> these test files and then regenerating the "good" data to match.

I don't see this as necessary, not yet.

Thanks.