Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
To: "Richard M. Heiberger" <rmh AT fisher DOT stat DOT temple DOT edu>
Cc: ntemacs-users AT cs DOT washington DOT edu, cygwin AT sourceware DOT cygnus DOT com,
        Chuck DOT Irvine AT mail DOT sprint DOT com
Subject: Re: ediff falsely identifying a difference as white space only
References: <200011300208 DOT VAA17667 AT fisher DOT stat DOT temple DOT edu>
From: Jason Rumney <jasonr AT gnu DOT org>
Date: 30 Nov 2000 20:48:44 +0000
In-Reply-To: <200011300208.VAA17667@fisher.stat.temple.edu>
Message-ID: <wk3dg9p4nn.fsf@segundo.gnu.org>
Lines: 29
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.92
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Richard M. Heiberger" <rmh AT fisher DOT stat DOT temple DOT edu> writes:

> This looks (again) like an issue that I raised some time ago (6-12
> months?).  ediff and ediff-3 were misbehaving with dos and mac line
> endings.  A fix was installed (ntemacs 20.6 ?) that worked correctly
> on NTemacs but not on other systems.  The fix reinvented something
> that was done differently in the development tree leading to emacs 21.
> There was some discussion among the developers about the best way to
> handle the line endings.  I remember that there was an issue about how
> to handle the --binary issue.  It was supposed to be sensitive to
> whether the diff program could use that argument.
> 
> The current discussion makes me think the alternate solutions were not
> completely reconciled.

I think the problem boiled down to the --binary option being necessary
to get certain aspects of ediff/emerge working properly on DOS and
Windows. In 20.7, the code was changed rather naively assuming that
all DOS/Windows ports of diff were ports of Gnu diff which understand
the --binary option. But this was found to be untrue, so in 21.1
(which is currently being pretested), the diff programs are checked to
see if they understand the --binary option rather than using it
blindly. This means that versions of diff that do not understand the
--binary option will still work for some cases (in 20.7 they do not
work at all), but you will still need a version that understands the
--binary option if you want perfect bug free ediffing.

-- 
Jason Rumney <jasonr AT gnu DOT org>



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com