Subject: Re: ediff falsely identifying a difference as white space only
From: Jason Rumney <[email-masked]>
To: "Richard M. Heiberger" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: 30 Nov 2000 20:48:44 +0000

"Richard M. Heiberger" <[email-masked]> 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 <[email-masked]>

--
Want to unsubscribe from this list?
Send a message to [email-masked]