From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: etags test is broken on MS-Windows Date: Fri, 22 May 2015 22:08:44 +0300 Message-ID: <837fs04egz.fsf@gnu.org> References: <83y4kmdjmj.fsf@gnu.org> <555A8E62.7060700@cs.ucla.edu> <83h9r8egen.fsf@gnu.org> <83pp5t6gex.fsf@gnu.org> <555E09AE.9070208@cs.ucla.edu> <83lhgh6fb2.fsf@gnu.org> <555E2C10.4010501@cs.ucla.edu> <83h9r5670s.fsf@gnu.org> <555E6A15.8010404@cs.ucla.edu> <831ti957wp.fsf@gnu.org> <83pp5s4uml.fsf@gnu.org> <555F740D.4030304@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1432321753 17872 80.91.229.3 (22 May 2015 19:09:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 May 2015 19:09:13 +0000 (UTC) Cc: pot@gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 22 21:09:05 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YvsJc-0002LB-Mq for ged-emacs-devel@m.gmane.org; Fri, 22 May 2015 21:09:04 +0200 Original-Received: from localhost ([::1]:35395 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvsJb-0004Fc-PT for ged-emacs-devel@m.gmane.org; Fri, 22 May 2015 15:09:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvsJQ-0004FW-5U for emacs-devel@gnu.org; Fri, 22 May 2015 15:08:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvsJL-0005Wp-3E for emacs-devel@gnu.org; Fri, 22 May 2015 15:08:52 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:56674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvsJK-0005Wh-Qy; Fri, 22 May 2015 15:08:47 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NOR00C00M74RM00@mtaout25.012.net.il>; Fri, 22 May 2015 22:04:34 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOR00BSPMBM8N10@mtaout25.012.net.il>; Fri, 22 May 2015 22:04:34 +0300 (IDT) In-reply-to: <555F740D.4030304@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186738 Archived-At: > Date: Fri, 22 May 2015 11:23:09 -0700 > From: Paul Eggert > CC: emacs-devel@gnu.org > > One possible way to do that is suggested in the last paragraph of > . > This approach does remove the different treatment of CRLF on MS-Windows > and Unix (as Francesco suggested); but it does so in a different way, by > using the Unix convention everywhere, and it suggests an approach that > should let Emacs do the right thing on both Unix and MS-Windows, without > any glitches on either platform. These byte counts are not file byte counts (if they were, then what you suggest would have been TRT). They are buffer byte counts, i.e. etags needs to compute the byte counts that Emacs will see when the file is visited in an Emacs buffer. So each CRLF EOL needs to be counted as 1 byte, not 2. Therefore, the DOS_NT code does TRT in this case, for both Windows and Posix hosts, as amazing as it sounds. It is, of course possible to let etags count file bytes, and then have etags.el correct those to get buffer bytes instead. But that doesn't sound right to me: first "break" the perfectly correct code, and then "unbreak" the result in Emacs. To say nothing of the fact that visiting a TAGS table will be slower that way. However, the issue is minor, and I really don't want to waste any more time arguing about it.