ediff falsely identifying a difference as white space only

Jason Rumney jasonr@gnu.org
Fri Dec 1 11:22:00 GMT 2000


"Richard M. Heiberger" <rmh@fisher.stat.temple.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@gnu.org>



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com



More information about the Cygwin mailing list