[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with the url package on w32?

From: Lennart Borgman
Subject: Re: Problems with the url package on w32?
Date: Thu, 21 Dec 2006 11:03:43 +0100
User-agent: Thunderbird (Windows/20061207)

Lennart Borgman wrote:
Juanma Barranquero wrote:
On 12/20/06, Eli Zaretskii <address@hidden> 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:


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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]