Re: Problems with the url package on w32?

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

Lennart Borgman wrote:
> Juanma Barranquero wrote:
>> On 12/20/06, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> I do, but I do it with "M-|", not with Ediff.
>>
>> I don't use ediff either. I was talking of cutting a patch from an
>> e-mail, for example, pasting it into a buffer, M-x diff-mode'ing and
>> doing C-c C-a. If your e-mail program did somehow alter the patch
>> (which Gmail does, unless you take pains to extract the patch from the
>> original view), C-c C-a often mistakenly says that it's applying hunks
>> which it's not.
>
> I tried to look into the problem with ediff-patch a bit. It took quite 
> some time to figure out what is going on. There are different bugs and 
> misfeatures.
>
> 1) First ediff-patch-file--internal calls call-process-region with a 
> shell as its program. This means that the file arguments must be 
> converted with convert-standard-filename. This is a clear bug.
>
> 2) Then ediff-shell has a bad initialization value in my opinion. On 
> w32 it is initialized to the value of shell-file-name at that time. 
> There is not very much sense in that. ediff-shell is used only 
> ediff-patch-file--internal. There it overrides shell-file-name. It 
> would be much better to initialize it to nil and then use this value 
> only if it is set. Otherwise shell-file-name should be used.
>
> 3) There is something very strange when calling patch this way from 
> emacs. It takes up to 10 s to apply that little patch Kim sent if 
> cmdproxy with gnuwin32 binaries or Cygwin is used as inferior shells. 
> Applying the patch from outside Emacs does not take any time at all 
> with gnubinaries in cmd.exe. Using MSYS for the inferior shell on the 
> other hand takes very little time. Is there something wrong with 
> cmdproxy and the call of it from emacs?
>
> Should I send patches for 1 + 2?

Looking into this a bit more I can see that 3 is probably a problem with 
line endings and the patch program. There might be more problems since 
cmdproxy is involved in the case taking long time (or actually just 
hangs) but not in the other, I am not sure about that. The problem with 
the line endings are however certain, see the end of this file for some 
tests of different patch programs on w32 I finished a year ago:

   http://ourcomments.org/GNU/patchcrlf/readme.txt

Now I believe that this is possible to solve within ediff if ediff 
always makes sure that the patch file and the file to patch always have 
the same line endings (and perhaps that this can be choosen to LF or 
CRLF). Further I think that the patched file of course should have the 
same line endings as the original file.


Michael, what do you think about this? I think the main part of this can 
be done in ediff-patch-file--internal, or?