Hmmm...True...But the strange thing is that it has been working for
quite a while and suddenly it stopped working.

I have probably changed something in my environment to cause this but I
can't figure out what that something is.

Hmmm...Now that I think about it I have actually upgraded Cygwin itself
to a newer version quite recently. Maybe something happened there.

Thanks for the pointer. :-D

Another thank you to all list members who provide me with thorough
solutions to problems I haven't even encountered yet. The VIM mailing
list is the one I learn the most from and I enjoy reading through each
and every email.

Best regards,
Joakim
 

On ons, 2006-11-29 at 21:30 +0100, A.J.Mechelynck wrote:
> Joakim Olsson wrote:
> > True. Sorry for being a bit brief. :-D
> > 
> > None of the VCS-commands for CVS seems to work. The actual command I
> > tried for the output below was from the VCSVimDiff-command which diffs
> > the current buffer with the latest revision from the CVS-tree (or a
> > specific revision that is supplied as an argument).
> > 
> > I would guess that the file is fetched from CVS as a temporary file and
> > then the regular diff-mode is enabled.
> > 
> > For some reason it can't seem to get that temporary file.
> > 
> > I'm using GVim 7.0 (don't remember which patches are applied, I'm at
> > home now and it struggles at work) on WinXP. I'm using the CVS-client
> > from the Cygwin package.
> > 
> > /Joakim
> 
> If you're using a native-Windows Vim with a Cygwin program, the former is 
> passing "Windows" paths C:\path\to\some\filename.exe to the latter, which 
> expects Unix-like paths /cygdrive/c/path/to/some/filename.ext instead; 
> vice-versa for returned path names.
> 
> Interfacing Cygwin programs with Windows programs usually requires filtering 
> all pathnames through the "cygpath" utility (see "info cygpath" or "cygpath 
> --help" -- whichever works). It is sometimes possible (compiling Vim with 
> +perl using Make_cyg.mak successfully invokes native-Windows Perl from Cygwin 
> make) but it is rarely easy.
> 
> 
> Best regards,
> Tony.
> 

Reply via email to