bug#4451: 23.1; EOL problems with vc-diff and cygwin

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Cc: 4451@emacsbugs.donarmstrong.com, Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 26 Sep 2009 10:27:38 +0200
> 
> On Fri, Sep 25 2009, Eli Zaretskii wrote:
> 
> >> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> [...]
> >> Eli didn't seem convinced about it.  And it may cause poor results
> >> in other cases as well.  I'm not familiar enough with the issue (which
> >> seems to be very w32-specific and depend heavily on the particular
> >> diff.exe tool you use), to make a good judgment call.
> >
> > What would be good is to investigate the original problem thoroughly
> > and post the exact reason(s) of the failure.  Reiner, could you perhaps
> > do that?  
> 
> I think I posted all data you asked for, or did I forget something?

You posted the data I asked for, yes (thanks!), but what I'm asking
now is different.

What I'd like to see is where in Emacs sources we examine the output
we get from Diff, and where and why we err as to what EOL format
should be used for decoding that output.

One possibility for this mistake might be that Diff produces
inconsistent EOL format in its output, for example if Diff or its VC
front-end outputs some headers that have Unix EOLs and then the actual
diffs with DOS EOLs.

Another possibility is that somewhere along the chain of processing
the output, we force EOL conversion to be Unix-style, instead of
detecting EOLs dynamically, or maybe even forcing it to DOS (if we
have clear evidence for doing the latter).

It could also be some mix of these.

These are just the hypotheses; only by tracing the processing through
its stages and taking notes for every stage that deals with decoding
output from external processes or from temporary files, it will be
possible to establish facts and determine what and where goes wrong.

TIA