Re: Problems with the url package on w32?

[Lennart Borgman]

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?