On Thu 7-Sep-06 10:01pm -0600, A.J.Mechelynck wrote:
> Bill McCarthy wrote:
>> To better understand what vimdiff is doing (and why it is so
>> slow), I had my shell (4NT under WinXP) keep a log showing
>> me just what was requested. [Note: I use '>!' instead of '>'
>> for redirection because my 4NT is set to not overwrite
>> existing files unless explicitly told to do so.]
>>
>> Invoking vimdiff with: gvim -d file1 file2
>>
>> I can see that the following 3 shell requests are made:
>>
>> diff -a VIo2A3F.tmp VIn2A40.tmp >!VId2A41.tmp
>> diff -a --binary VIo2A3F.tmp VIn2A40.tmp >!VId2A41.tmp
>> diff -a --binary VIo2A3F.tmp VIn2A40.tmp >!VId2A41.tmp
>>
>> The log shows about 4 seconds between commands.
>>
>> I would have thought that the first diff would provide
>> enough information. What is the purpose of the other two?
> Just guessing.
>
> As noted in the help (e.g. under ":help 'diffexpr'), vimdiff uses
> ed-style diffs, which (unlike context or unified diffs) are not
> reversible. It may need those three calls to properly highlight both
> windows of the vimdiff. The fact that the temporary files' _names_ are
> the same between calls doesn't prove that their _contents_ are the same.
Good point, the contents must be different if the 3
invocations are useful. A quick look at the code, seems to
show redundant calls because of uncertainty whether the
return codes are reliable. My diff appears to always return
a 0 when the files are the same, and a 1 when they are
different.
> Or you may have a nonstandard diff.exe: the --help for my GNU diff
> (version 2.8.7) makes no mention of a --binary argument.
Perhaps I need an upgrade:
[c:\pad]diff --version
diff - GNU diffutils version 2.7
Since this is also located in my $vimruntime, I assume it
was packed with the original 7.0 for Windows. BTW, it is
clearly Vim providing that --binary flag - something about
the old ctrl-z stuff, in the first versions of DOS, possibly
ending the process early.
--
Best regards,
Bill
