` Ben Fritz wrote:
On Oct 12, 6:47 pm, Linda W <v...@tlinx.org> wrote:
Jürgen Krämer wrote:(at least when I launch from explorer...)...so if it
finds my .vim and .gvim, why doesn't it find .vim/colors/xxxx.vim?did you
change the 'runtimepath' option? On Windows the directory for user-specific
scripts is ~/vimfiles by default, not ~/.vim.---
I don't set a runtime path. I'd expect it to work the same as on
unix/linux.
Why should windows be different?
IMO, it should look for .vim first, and then any old-style compat name,
but **not
looking** for ~/.vim at all would seem to be a bug.
Vim also doesn't seem to find
The problem with using .vim and .vimrc on Windows, is that the Windows
file explorer (as of Windows XP, I'm not sure about Vista or Windows
7) will simply not allow you to create files or directories with names
which begin with a '.' character. Sure, you can create them from the
command-line, or from within Vim, but the average user doesn't want to
do that.
----
That's not a problem at all.
I cite the documented search order for .vim/.gvim:
c. Four places are searched for initializations. The first that exists
is used, the others are ignored. The $MYVIMRC environment variable is
set to the file that was first found, unless $MYVIMRC was already set
and when using VIMINIT.
- The environment variable VIMINIT (see also |compatible-default|) (*)
The value of $VIMINIT is used as an Ex command line.
- The user vimrc file(s):
"$HOME/.vimrc" (for Unix and OS/2) (*)
"s:.vimrc" (for Amiga) (*)
"home:.vimrc" (for Amiga) (*)
"$VIM/.vimrc" (for OS/2 and Amiga) (*)
"$HOME/_vimrc" (for MS-DOS and Win32) (*)
"$VIM/_vimrc" (for MS-DOS and Win32) (*)
Note: For Unix, OS/2 and Amiga, when ".vimrc" does not exist,
"_vimrc" is also tried, in case an MS-DOS compatible file
system is used. For MS-DOS and Win32 ".vimrc" is checked
after "_vimrc", in case long file names are used.
Note: For MS-DOS and Win32, "$HOME" is checked first. If no
"_vimrc" or ".vimrc" is found there, "$VIM" is tried.
See |$VIM| for when $VIM is not set.
- The environment variable EXINIT.
The value of $EXINIT is used as an Ex command line.
- The user exrc file(s). Same as for the user vimrc file, but with
"vimrc" replaced by "exrc". But only one of ".exrc" and "_exrc" is
used, depending on the system. And without the (*)!
=================================
Comments:
1) that .vim isn't searched for in the same way with 'vimfiles', is a
rather glaring BUG, given the above. It's incompatible with the
documented procedures for checking the names of .vimrc, .gvimrc, and .exrc.
2) I'm running on Win64, that has more feature in common with linux in
not limiting one to the lower 4G of memory, but realistically, the break
should have been made at MS-DOS/Win32.
3) the reason it checks for .vimrc after, is, it claims, 'in case long
filenames are use'
In XP and above (running on an NTFS disk) it can never be the case that
long filenames are not usable but it is the case that shortname creation
can be disabled.
All of my systems since about 2000 on, have had short-name creation
turned off. (Side note: On Win7, I've actually removed most of the
shortnames that were created before I turned off 8.3 name compat). The
tool that helps you do this tells you what registry entries might remain
so you can clean up your registry and change those entries to point to
the new name)
But I would argue that as the default on NTFS is long-names, then .vimrc
should always be checked first on systems based on NTFS (XP and above
the default was NTFS, and in XP they crippled creation of large drives
other than in NTFS.
I.e. -- the reasons giving any preference for .vim* over _vim* are
VERY dated. The best reason for even keeping _vimrc at all (besides
grandfathering and no reason to break things needlessly, which are both
good reasons by themselves), is your point (surprised me!)...that
explorer is broken. How lame!
Although, a minor counterpoint to that: what you say might be a reason
for supporting _gvimrc, but _vimrc, while usable for both, for console
use (though it can be used for both). But if someone isn't using
console, they could just put everything in _gvimrc...(note: playing
devil's advocate there, as my real pref would be to keep
_vimrc/_gvimrc/vimfiles/ supported, but have .vimrc/.gvimrc/.vimfiles be
what is searched for first on any NTFS or networked file system. Not
since FAT12/16 have you not been able to use .vim. and those are VERY old.
Now...I'm running Win64, not Win32, and run Win32 programs in a
NON-native System Windows on Windows SYSWOW64 that runs 32bit progs on
Win64. That they run at all took extra (though essential) work on the
part of MS. They chose, by default, to NOT support Win32 drivers. So
one could argue that the above exceptions for MS/DOS+Win32 shouldn't
even be applied in a Win64 environment.
So take your pick from the above, I think I covered all points and
objects and then some.
The current behavior is broken, anyway you look at it, and it's
conceptually wrong for any NTFS based OS.
Can we please move toward fixing this long annoying problem?
--
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
