> Ben Fritz wrote:
> The only reason Vim uses vimfiles at all on Windows, is that on
> Windows, 'runtimepath' defaults to including vimfiles instead of .vim.
> We could default to include BOTH, however this could easily break a
> lot of systems already out there, for example if they symlink .vim to
> vimfiles so they can use the same config on Cygwin/Linux.
>
>
> ====
> How?
> If vimfiles is a symlink to .vim, and it encounters .vim first... it will read
> it as .vim and stop looking for it.
> I.e. this isn't an issue for the multitude of people who have links from _vimrc
> --> .vimrc
By including both, I think Ben meant that 'runtimepath' would
contain the union of the Windows 'runtimepath' and the Unix
'runtimepath', e.g.,
"$HOME/.vim,
"$HOME/vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
$HOME/.vim/after",
$HOME/vimfiles/after"
With that approach, and a symlink between $HOME/.vim and
$HOME/vimfiles, the files in the $HOME/*/after directories would
sourced twice.
> You could do something fancy like check for the existence of both and
> only add .vim if both exist by default, but it's hard to know what's
> correct. And it's trivial to do what you want in vimscript.
>
>
> ----
> Why should vim do anything different with .vim/vimfiles than .vimrc/_vimrc ?
> I would have to strongly disagree. It's the fact that it is doing something
> completely inconsistent and different that is causing the problem.
The differences are: one is a file and the other is a directory;
and one is read only once, at startup, while the other is read
almost every time a buffer is opened.
> MAYBE the best solution would be to have some logic in
> vimrc_example.vim, which is sourced by default on a fresh Windows
> install, which checks for the existence of .vim/vimfiles and sets the
> runtimepath differently if .vim exists but vimfiles does not. But I
> don't think changing the default value in the C code is a good idea.
> It would break tons of systems in use now, and make documentation in
> Vim and on the Internet outdated.
>
>
> ----
> Fixing a bug can always cause compat problems. When bash stopped ignoring
> "\r" ininput lines by default, it caused a bunch of people's scripts to break.
> But that didn't stop progress. People fixed their scripts and life went on.
> BUT, I don't see that changing defaults will necessarily break anything.
> It makes for fewer 'special cases', and makes the code more robust and less
> likely to fail, overall, and
> creates less confusion about...what's being read and where,..
The current behavior is not a bug. This behavior is intentional.
Vim was designed to work this way and it works as designed. This is
not a bug.
I just don't see the problem. I currently have Vim installed on two
Windows machines and four Linux machines, all using the same
configuration files, distributed using Dropbox. On Windows, the
files are $HOME/_vimrc and $HOME/vimfiles; on Linux, they are
$HOME/.vimrc and $HOME/.vim. Odd, but simple. Having two sets of
configuration file names hasn't broken anything and hasn't caused
any confusion.
If you think Vim should automatically determine whether to use
$HOME/vimfiles or $HOME/.vim, then you need to decide whether Vim
should make this determination once at startup or every time it
accesses 'runtimepath'. The latter will affect performance which
could be a problem. The former is easy to implement in your
.vimrc/_vimrc, as Ben said. For example (untested--the let rhs
probably needs to be expanded):
if has("win32") && isdirectory(expand("$HOME")."/.vim")
let &rtp = "$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after,$HOME/.vim/after"
endif
Regards,
Gary
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment