From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.comp.gnu.utils.bugs,gmane.emacs.devel Subject: Re: diff-mode misinterprets empty lines. Date: Wed, 05 Dec 2007 15:59:11 +0100 Message-ID: <854pexur0g.fsf@lola.goethe.zz> References: <85ir3l767y.fsf@lola.goethe.zz> <87ir3d1tn7.fsf@penguin.cs.ucla.edu> <878x494f9w.fsf@rho.meyering.net> <857ijtwgpw.fsf@lola.goethe.zz> <87k5nt2xga.fsf@rho.meyering.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196868938 25182 80.91.229.12 (5 Dec 2007 15:35:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2007 15:35:38 +0000 (UTC) Cc: Paul Eggert , bug-gnu-utils@gnu.org, Stefan Monnier , rms@gnu.org, emacs-devel@gnu.org To: Jim Meyering Original-X-From: bug-gnu-utils-bounces+gnu-bug-gnu-utils=m.gmane.org@gnu.org Wed Dec 05 16:35:48 2007 Return-path: Envelope-to: gnu-bug-gnu-utils@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IzwHY-0006qs-RZ for gnu-bug-gnu-utils@m.gmane.org; Wed, 05 Dec 2007 16:35:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzwHI-0007J6-6J for gnu-bug-gnu-utils@m.gmane.org; Wed, 05 Dec 2007 10:35:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzwHF-0007GM-3G for bug-gnu-utils@gnu.org; Wed, 05 Dec 2007 10:35:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzwHD-0007Ck-Fv for bug-gnu-utils@gnu.org; Wed, 05 Dec 2007 10:35:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzwHD-0007CD-4u; Wed, 05 Dec 2007 10:35:07 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IzwHC-0001Le-MI; Wed, 05 Dec 2007 10:35:06 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IzwH6-0004rD-9u; Wed, 05 Dec 2007 10:35:00 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 390301C40B64; Wed, 5 Dec 2007 15:59:12 +0100 (CET) In-Reply-To: <87k5nt2xga.fsf@rho.meyering.net> (Jim Meyering's message of "Wed, 05 Dec 2007 12:27:33 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: bug-gnu-utils@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports for the GNU utilities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-utils-bounces+gnu-bug-gnu-utils=m.gmane.org@gnu.org Errors-To: bug-gnu-utils-bounces+gnu-bug-gnu-utils=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.gnu.utils.bugs:15309 gmane.emacs.devel:84734 Archived-At: Jim Meyering writes: > David Kastrup wrote: > >> No, it does not make sense to change the default. Emacs is just one of >> many tools processing diff output. I remember gratuitous breakage of >> git, too. There are far too many tools relying on the _documented_ diff >> output formats (please read >> (info "(diff) Context") > > My sole interest is in the change to the *unidiff* format. > And that was not documented, back then. Huh? What makes you say that? >> for a detailed explanation of the diff formats) that it makes sense >> breaking things all around for no tangible benefit. > > The benefit was tangible enough to me to propose the change, and to > Paul to allow and extend it. I'm sure you know that git tools have > been accepting the trailing-blank-free format for over a year, so they > too saw some benefit in accepting the new format. Huh? What tangible benefit is "does not break in newer versions but only gets less reliable"? > Too many tools these days can automatically remove trailing blanks. Why would you apply them to a _diff_? > If I keep my code free of trailing blanks (and I do), those tools > should have no affect on my code. But your code is written as _diffs_. diffs are _output_ formats, not input formats. > I want the same benefit for diffs of my code. What benefit? > IMHO, it's an improvement at least to allow a trailing-blank-free diff > format. We are not talking about whether it makes sense for Emacs diff to be able to work around the output of broken file transfers. We are talking about whether it makes sense to break the output in the first place. And a "trailing-blank-free diff format" gained in this manner is an illusion, anyway, since diff must be able to represent lines differing in trailing space. >> I don't understand why this change was made in the first place, and I >> don't understand why people would want to gratuitously make the >> format less reliable to parse by tools, when the main usage _is_ the >> application by independent tools. > > You seem to underestimate Paul's concern for portability. Huh? How does one gain portability by breaking output formats? > Git was young at the time, and the format they cared about was > unidiff, so it wasn't *that* big a deal to fix it. Huh? What do you mean by "fix it"? > If we had known about the incompatibility with diff-mode back then, > I'm sure the new behavior would never have been made the default. We are not talking about an "incompatibility with diff-mode". We are talking about breaking the format specification. That concerns _any_ tool reading the output of diff, not just diff-mode. So again: where is the tangible benefit of breaking diff output in the first place? Because broken communication channels might break it, too? What kind of benefit is it to prebreak it? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum