From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jim Meyering Newsgroups: gmane.comp.gnu.utils.bugs,gmane.emacs.devel Subject: Re: diff-mode misinterprets empty lines. Date: Wed, 05 Dec 2007 12:27:33 +0100 Message-ID: <87k5nt2xga.fsf@rho.meyering.net> References: <85ir3l767y.fsf@lola.goethe.zz> <87ir3d1tn7.fsf@penguin.cs.ucla.edu> <878x494f9w.fsf@rho.meyering.net> <857ijtwgpw.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196854079 4965 80.91.229.12 (5 Dec 2007 11:27:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2007 11:27:59 +0000 (UTC) Cc: Paul Eggert , bug-gnu-utils@gnu.org, Stefan Monnier , rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: bug-gnu-utils-bounces+gnu-bug-gnu-utils=m.gmane.org@gnu.org Wed Dec 05 12:28:08 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 1IzsQA-0001RE-5H for gnu-bug-gnu-utils@m.gmane.org; Wed, 05 Dec 2007 12:28:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzsPt-0007Gr-Il for gnu-bug-gnu-utils@m.gmane.org; Wed, 05 Dec 2007 06:27:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzsPp-0007D6-P8 for bug-gnu-utils@gnu.org; Wed, 05 Dec 2007 06:27:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzsPo-00079y-0U for bug-gnu-utils@gnu.org; Wed, 05 Dec 2007 06:27:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzsPn-00079h-Nk; Wed, 05 Dec 2007 06:27:43 -0500 Original-Received: from smtp3-g19.free.fr ([212.27.42.29]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IzsPe-0004fu-RD; Wed, 05 Dec 2007 06:27:35 -0500 Original-Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 3F59D17B586; Wed, 5 Dec 2007 12:27:34 +0100 (CET) Original-Received: from mx.meyering.net (mx.meyering.net [82.230.74.64]) by smtp3-g19.free.fr (Postfix) with ESMTP id 235B417B55A; Wed, 5 Dec 2007 12:27:34 +0100 (CET) Original-Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id 05FFB8F05; Wed, 5 Dec 2007 12:27:34 +0100 (CET) In-Reply-To: <857ijtwgpw.fsf@lola.goethe.zz> (David Kastrup's message of "Wed, 05 Dec 2007 11:58:35 +0100") Original-Lines: 48 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:15305 gmane.emacs.devel:84727 Archived-At: David Kastrup wrote: > Jim Meyering writes: > >> Since I was thinking of using that new option always, I considered >> changing the source to make the default in my private binary be to >> enable the new option. Since I'd rather not have to make private >> changes, what do you think about having a compile-time option to >> change the default? Not even a configure-time flag. >> >> Since Emacs may eventually change to accept the new format, it may >> make sense to change the default and to provide a >> --no-suppress-blank-empty option. > > 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") Hi David, My sole interest is in the change to the *unidiff* format. And that was not documented, back then. > 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. Too many tools these days can automatically remove trailing blanks. If I keep my code free of trailing blanks (and I do), those tools should have no affect on my code. I want the same benefit for diffs of my code. IMHO, it's an improvement at least to allow a trailing-blank-free diff format. > 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. 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. 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.