Re: etags test is broken on MS-Windows

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 21 May 2015 15:16:01 +0200
> From: Francesco Potortì <pot@gnu.org>
> Cc: emacs-devel@gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> 
> >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?
> 
> Those files were put there to test the behaviour of etags with different
> EOL styles. However, few tests were in fact done for etags running on
> DOS systems, so in fact there may be undetected regressions on etags for
> DOS.

There's no problem with etags on DOS and Windows, it behaves exactly
as designed and implemented.  The problem is on Unix: because etags on
Unix does not strip the CR characters, its character counts are wrong,
because Emacs will strip them when it reads the source file.

IOW, what was at some point only done by Emacs on DOS and Windows, is
now done by default on all platforms.  So I think etags should use teh
same code in Unix as well.  I mean this fragment:

	if (c == '\n')
	  {
	    if (p > buffer && p[-1] == '\r')
	      {
		p -= 1;
  #ifdef DOS_NT
	       /* Assume CRLF->LF translation will be performed by Emacs
		  when loading this file, so CRs won't appear in the buffer.
		  It would be cleaner to compensate within Emacs;
		  however, Emacs does not know how many CRs were deleted
		  before any given point in the file.  */
		chars_deleted = 1;
  #else
		chars_deleted = 2;
  #endif
	      }