[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim-dev
Subject:    RE: BufReadCmd autocommands
From:       "Moore, Paul" <Paul.Moore () uk ! origin-it ! com>
Date:       2000-09-27 8:39:31
[Download RAW message or body]

From: Bram Moolenaar [mailto:Bram@moolenaar.net]
> > To see the effect, execute
> > 
> >     au BufReadCmd * echo expand("<afile>")
> > 
> > Then, :e a/b/c displays "a\b\c" - in other words, the 
> > forward slashes are
> > translated to backslashes.
[...]
> This is not very easy.  The wildcard expansion changes the slashes to
> backslashes.  This is done very early in the command parsing. 
> Keeping the slashes may cause new problems, this would require
> careful checking.  It's also not easy to keep the argument from
> before the expansion (and it's wrong if there really were wildcards).
> 
> Why do the backslashes cause trouble?  In Windows these two 
> commands should be equivalent:
> 
> 	:e a/b/c
> 	:e a\b\c

Because the NetRW commands install a BufReadCmd autocommand which looks for
filenames like

    ftp://server/path/to/file

and translates that into a series of FTP commands.

But the translation changes this to ftp:\\server\path\to\file, which is not
handled correctly by the FTP command...

More generally, I would imagine that the whole point of the BufReadCmd
autocommands would be to trap things which are *not* genuine filenames, and
process them specially. So in that case, translating them as if they were
filenames is likely to be wrong...

I suppose that the NetRW stuff could "undo" the translation, by converting
backslashes back into slashes. That would break use of files (on Unix) with
genuine backslashes in their names, but that shouldn't be very common...

Paul.

[prev in list] [next in list] [prev in thread] [next in thread]