emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: etags test is broken on MS-Windows


From: Eli Zaretskii
Subject: Re: etags test is broken on MS-Windows
Date: Thu, 21 May 2015 19:31:34 +0300

> Date: Thu, 21 May 2015 15:16:01 +0200
> From: Francesco Potortì <address@hidden>
> Cc: address@hidden, Paul Eggert <address@hidden>
> 
> >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
              }




reply via email to

[Prev in Thread] Current Thread [Next in Thread]