Can't get vim to use custom color in personal folder(finds .vimrc/.gvimrc but not .vim/colors/name.vim)
Linda W
I'm trying to place my color.vim file in
~/.vim/colors/linda.vim
But it is not finding it.
I've only been able to get it to work by putting it
C:\prog64\vim\colors\
(note I constantly have to move new 'vims' out of prog64\vim\vimXXX up
into vim,
upon new installations so all the programs that look for it at a fixed
location don't
break; don't actually move it, just create links)...
It finds my .vimrc, and .gvimrc. in C:\users\linda (~), which is what
I get if I type echo $HOME in gvim, (win7-64bit version)...
(at least when I launch from explorer...)...so if it finds my .vim and
.gvim,
why doesn't it find .vim/colors/xxxx.vim?
Jürgen Krämer
Hi,
did you change the 'runtimepath' option? On Windows the directory for
user-specific scripts is ~/vimfiles by default, not ~/.vim.
Regards,
J�rgen
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
Linda W
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
Chris Sutcliffe
>
> 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?
Assuming you are trying to mix Cygwin and Windows (g)vim, in Cygwin just
make .vim a symlink to vimfiles. I do that and it works quite well.
Chris
--
Chris Sutcliffe
ir0n...@gmail.com
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
Jürgen Krämer
Hi,
Chris Sutcliffe wrote:
> On 12/10/2011 7:47 PM, Linda W 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?
>
> Assuming you are trying to mix Cygwin and Windows (g)vim, in Cygwin just
> make .vim a symlink to vimfiles. I do that and it works quite well.
putting
set runtimepath=~/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after,~/.vim/after
in you .vimrc or _vimrc also works.
Dan Wierenga
On 12/10/2011 7:47 PM, Linda W wrote:Assuming you are trying to mix Cygwin and Windows (g)vim, in Cygwin just make .vim a symlink to vimfiles. I do that and it works quite well.
I don't set a runtime path. I'd expect it to work the same as on unix/linux.
Why should windows be different?
And even if you're not, the newer versions of Windows (since Vista, IIRC) support symlinks . Open up cmd.exe and type "mklink".
Ben Fritz
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.---
> 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
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.
The default Windows setting, to hide the extension for known file
types, will probably make matters worse. I expect, though I have not
confirmed, that if you were to have a file association for .vim files,
that a .vim folder may cause some strange behavior.
Alessandro Antonello
> 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.
>
> The default Windows setting, to hide the extension for known file
> types, will probably make matters worse. I expect, though I have not
> confirmed, that if you were to have a file association for .vim files,
> that a .vim folder may cause some strange behavior.
>
Hi,
I use VIM/GVIM in a common configuration between a Windows (XP) box,
Cygwin (on that Windows) and a Mac. In my Mac I installed the MacVim
version 7.3, in the Windows I have the GVim 7.0 and in the Cygwin
(with GTK Vim to work with XWindow server) the 7.3 version. All these
installations are using the same configuration files.
The files are synchronized between Mac and Windows using Dropbox. So
if I made some changes in one machine I will get the same changes in
other. A tweak part was set the default font on startup. I love DejaVu
so I installed it in all machines.
Well, this is what I did:
1. In the Mac the configuration was strait forward. The files
'.vimrc', '.gvimrc' and the directory '.vim' are in my home directory.
All Vim scripts are in Unix format, that is important.
2. In the Windows box I set a '$HOME' environment variable to mimic
the way Mac and Unix works. So I defined this variable to something
like 'C:\users\Alessandro'.
3. In my new 'Windows user directory' I put the Vim files '.vimrc' and
'.gvimrc' and the directory '.vim'. In '.vimrc' file I changed the
'runtimepath' so Vim can see the '.vim' directory. But only when it is
loaded from Windows or a DOS box.
When I start Vim/GVim from Cygwin or CygwinX all is perfectly normal.
The '$HOME' environment variable is already there so 'Cygwin' will
treat my directory as usual, also Vim.
Why I did all that? Well, these days I work mostly in the Mac. But
sometimes I need to do some work on Windows. But, I am so comfortable
with the way *nix systems works that I can leave in a Windows system
without cygwin. Well, there I did some apps for Windows Mobile using
CeGCC.
I almost forgot. I also have a MinGW installation, in my Windows, that
has it's own version of Vim. It uses the same configuration files
since the '$HOME' variable is also used by MSYS.
What a mess!!
--
Alessandro Antonello
George V. Reilly
I share my Vim configuration and other dotfiles between Windows, Mac,
and Linux. It's stored in a private repository at GitHub. I create a
working copy at C:\gvr or ~/gvr. Inside there, I have several
directories, including dotfiles and vimfiles.
Here's a *partial* view from `tree`:
/Users/georger/gvr/
├── _vimrc
├── dotfiles
│ ├── bash_aliases
│ ├── bash_logout
│ ├── bashrc
│ ├── emacs.d
│ │ ├── init.el
│ ├── gitconfig.mac
│ ├── gitconfig.msys
│ ├── makelinks
│ ├── makelinks.cmd
│ └── viper
├── vimfiles
│ ├── after
│ │ ├── ftplugin
│ │ └── syntax
│ ├── autoload
│ ├── bundle
│ │ ├── bufexplorer
│ │ ├── dbext
│ │ ├── fugitive
│ ├── plugin
I use the makelinks scripts to symlink
Here's the Mac/Linux makelinks:
#!/bin/bash
ln -s -f ~/gvr/ctags.cnf ~/.ctags
ln -s -f ~/gvr/_vimrc ~/.vimrc
ln -s -f ~/gvr/vimfiles ~/.vim
ln -s -f ~/gvr/dotfiles/gitconfig.mac ~/.gitconfig
ln -s -f ~/gvr/dotfiles/emacs.d ~/.emacs.d
for i in bashrc bash_aliases bash_profile bash_logout profile viper
do
ln -s -f ~/gvr/dotfiles/$i ~/.$i
done
And the Windows one. Note %HOME% is set to C:\gvr:
:: Vista or Win7 only. Must be run as Administrator from a cmd window
pushd %~dp0
for %%i in (bash* profile viper) do (mklink ..\.%%i dotfiles\%%i)
mklink ..\.gitconfig dotfiles\gitconfig.msys
mklink /d ..\.emacs.d dotfiles\emacs.d
mklink /d ..\Dropbox "%USERPROFILE%\Dropbox"
popd
This works fine with programs running in the regular Windows cmd window,
as well as the MsysGit Bash window.
--
/George V. Reilly geo...@reilly.org Twitter: @georgevreilly
http://www.georgevreilly.com/blog http://blogs.cozi.com/tech
Linda W
` 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 findThe 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?
Ben Fritz
On Oct 25, 2:52 am, Linda W <v...@tlinx.org> wrote:
>
> 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.
>
the runtimepath. There is only one .vimrc. If a .vimrc is found,
_vimrc won't be used at all (or maybe it's the other way around,
regardless, only one is sourced). With the runtimepath, you could
potentially have both vimfiles AND .vim in the path, and source files
from both.
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.
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.
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.
Linda W
Ben Fritz wrote:
On Oct 25, 2:52 am, Linda W <v...@tlinx.org> wrote: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.But, unlike the .vimrc/.gvimrc, any number of directories can be in the runtimepath. There is only one .vimrc.
isn't ".vim" searched for in the same locations as .vimrc/.gvimrc??
I wasn't asked for it to be searched for in the runtime path. I am under (perhaps, the "mis-"), that
.vim as a dir was searched for along for, or in the same way as .vimrc/.gvimrc and the breakage occurred because on Windows it uses a 15-20'yro restriction on filenames that applied to FAT to use another yet another special name for the sake of FAT12/16 & MS-DOS.
I'm not talking about the 'VIMRUNFILES' where vim finds its own runfiles...but the
USER rules that are read along side the "built-in" vimruntime dir files.
----
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
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.
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,..
Gary Johnson
> 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
Ben Fritz
On Oct 25, 11:39 am, Linda W <v...@tlinx.org> wrote:
> Ben Fritz wrote:On Oct 25, 2:52 am, Linda W<v...@tlinx.org>wrote: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.But, unlike the .vimrc/.gvimrc, any number of directories can be in the runtimepath. There is only one .vimrc.Sorry, but you lost me. you can have any number of dirs named .vim? Huh?
> I wasn't asked for it to be searched for in the runtime path. I am under (perhaps, the "mis-"), that
> .vim as a dir was searched for along for, or in the same way as .vimrc/.gvimrc and the breakage occurred because on Windows it uses a 15-20'yro restriction on filenames that applied to FAT to use another yet another special name for the sake of FAT12/16 & MS-DOS.
> I'm not talking about the 'VIMRUNFILES' where vim finds its own runfiles...but the
> USER rules that are read along side the "built-in" vimruntime dir files.
> If vimfiles is a symlink to .vim, and it encounters .vim first... it will read it as .vim and stop looking for it.
What I mean, is that while Vim only finds and reads a single .vimrc
file, then stops, this is NOT what happens with the folders in
"vimfiles". The ONLY reason Vim reads the contents of $HOME/vimfiles,
is because by default, the 'runtimepath' option is:
Unix: "$HOME/.vim,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
$HOME/.vim/after"
Amiga: "home:vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
home:vimfiles/after"
PC, OS/2: "$HOME/vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
$HOME/vimfiles/after"
Macintosh: "$VIM:vimfiles,
$VIMRUNTIME,
$VIM:vimfiles:after"
RISC-OS: "Choices:vimfiles,
$VIMRUNTIME,
Choices:vimfiles/after"
VMS: "sys$login:vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
sys$login:vimfiles/after")
Here, I assume "PC" refers to Windows. I observe my own runtime path
(which I do not touch) matches this assumption.
As you can see, a Vim OPTION controls which directory is searched for
config files. If you set this option to explicitly check $HOME/.vim
instead of $HOME/vimfiles on Windows, Vim will use that directory
instead. You could also set Unix to use $HOME/vimfiles instead of
$HOME/.vim. You could even dispense with vimfiles/.vim entirely, and
have both systems check $HOME/config/editors/vim or something wild
like that. Nothing at all binds Vim to using .vim or vimfiles, other
than that's the default value of the 'runtimepath' option.
In fact, various plugin-management plugins like Pathogen take
advantage of this, allowing you to install every one of your plugins
in their own directory for easier update or removal. The underlying
method to accomplish this, is to set your runtimepath to contain all
these directories.
Now, a big difference between .vimrc and the files which by default
are looked for in ~/.vim, is that Vim DOES NOT stop when it encounters
a match. It keeps going, grabbing ALL matches. So, with the default
runtimepath on Unix, Vim will source anything in:
$HOME/.vim/plugin
$VIM/vimfiles/plugin
$VIMRUNTIME/plugin
$VIM/vimfiles/after/plugin
$HOME/.vim/after/plugin
...in that order.
This is by design. It allows users to very easily override anything in
plugins or VIMRUNTIME files, and/or install plugins for use on a
system at large which every user need not install but can probably
use.
Now, you're proposing that Windows is inconsistent, because it doesn't
check the $HOME/.vim directory. I would counter that it is truly Unix
that is inconsistent. Out of all the systems with default values for
'runtimepath' listed, Unix is the only one which uses .vim. Every
other system, and indeed Unix itself for the non-user-specific files,
use "vimfiles". So, if any change is made, logically it would be to
default Unix Vim to using $HOME/vimfiles, rather than defaulting
Windows to use $HOME/.vim.
And I'm sure we can safely assume that Unix users everywhere would be
angry for years if Bram decided one day to use vimfiles rather
than .vim for the default Unix Vim config.
Ben Fritz
On Oct 25, 12:45 pm, Gary Johnson <garyj...@spocom.com> wrote:
>
> 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
>
Something like this could be placed in vimrc_example.vim, which AFAIK
is sourced by default in a brand-new Windows installation:
" check for $HOME/.vim existing INSTEAD of $HOME/vimfiles, in case Vim
users from Unix aren't paying attention
if has("win32") && isdirectory(expand("$HOME")."/.vim") && !
isdirectory(expand("$HOME")."/vimfiles")
let &rtp = "$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/
after,$HOME/.vim/after"
endif
(still untested...potentially as Gary says the RHS needs to be
expanded)
Charles Campbell
>
> And I'm sure we can safely assume that Unix users everywhere would be
> angry for years if Bram decided one day to use vimfiles rather
> than .vim for the default Unix Vim config.
>
>
Linda W
George V. Reilly wrote:
On Fri, Oct 14, 2011 at 2:50 PM, Alessandro Antonello wrote:
On Fri, Oct 14, 2011, at 9:41 AM, Ben Fritz wrote:
The default Windows setting, to hide the extension for known file types, will probably make matters worse. I expect, though I have not confirmed, that if you were to have a file association for .vim files, that a .vim folder may cause some strange behavior.
BTW, this part -- I disagree with... if it hid the .vim
file that'd be find w/me, but I have
the option: "always display hidden files" checked on (it's the only
sane setting), because in explorer, you can't easily toggle the option
on/off as you can on the command line. Thus you need to keep it on all
the time, or the pain of turning it on globally and then back off gain
will dissuade you from ever looking when the consequences of not doing
so will cause "bad things to happen"(c).
Hi, I use VIM/GVIM in a common configuration between a Windows (XP) box, Cygwin (on that Windows) and a Mac. In my Mac I installed the MacVim version 7.3, in the Windows I have the GVim 7.0 and in the Cygwin (with GTK Vim to work with XWindow server) the 7.3 version. All these installations are using the same configuration files
The files are synchronized between Mac and Windows using Dropbox. So if I made some changes in one machine I will get the same changes in other. A tweak part was set the default font on startup. I love DejaVu so I installed it in all machines.
Well, this is what I did:
Complicated workaround, a good example
of why this bug needs fixing, deleted
as it's a "red herring". But it is a good example of why this bug
needs fixing. That's only 1 example of the pain users must go through
to get around this bug.
Exactly!!! A beautiful example and comment of WHY this bug NEEDS to be fixed.What a mess!!
Next person...
I share my Vim configuration and other dotfiles between Windows, Mac,
and Linux. It's stored in a private repository at GitHub. I create a
working copy at C:\gvr or ~/gvr. Inside there, I have several
directories, including dotfiles and vimfiles.
[dir struct deleted]
#!/bin/bash
ln -s -f ~/gvr/ctags.cnf ~/.ctags
ln -s -f ~/gvr/_vimrc ~/.vimrc
ln -s -f ~/gvr/vimfiles ~/.vim
----Now ya see, a couple of other 'chicken-littles' are spreading the FUD that this
will cause the sky to fall and the end of life as we know it. WHAT ARE YOU DOING?! ( :-) )
ln -s -f ~/gvr/dotfiles/gitconfig.mac ~/.gitconfig
ln -s -f ~/gvr/dotfiles/emacs.d ~/.emacs.d
for i in bashrc bash_aliases bash_profile bash_logout profile viper
do
ln -s -f ~/gvr/dotfiles/$i ~/.$i
done
What are those for? some other broken, OLD MS-DOS era convention for FAT12/16
filesystems? used by some other tool? or is that for Vim too?
And the Windows one. Note %HOME% is set to C:\gvr:
"is set" -- I like that. Not by MS. Not by anyone unless you add it to each
machine, ... and then you better make it HOME=%HOMEDRIVE%%HOMEDIR%
:: Vista or Win7 only. Must be run as Administrator from a cmd window
pushd %~dp0
for %%i in (bash* profile viper) do (mklink ..\.%%i dotfiles\%%i)
mklink ..\.gitconfig dotfiles\gitconfig.msys
mklink /d ..\.emacs.d dotfiles\emacs.d
mklink /d ..\Dropbox "%USERPROFILE%\Dropbox"
popd
Another example of why this needs to be fixed. Though I'll share MY config and why the above methods (and mine) don't work and the solution is to fix the bug, NOT develop kludge-arounds.
My setup is about 2-3 times as complicated as either as they above two. When things were perfect, they worked, but when Windows syncing with it's domain controller became unreliable, all delicate balance went to crap.
1) started with ~/.vimrc on unix and linux
2) copied that to WinXP env for cygwin, where it set 'HOME'...
3) found native version of vim/gvim, with some better adaptations
to windows env, something that
was made much more necessary on Vista/Win7 where 32-bit procs get
different file system views). In order to improve running of of cygwin
programs from win32 in the scheduler, or as targets of explorer links
I exported HOME from cygwin to my env.
Initially, I had them share their runtime dirs. Had to strip the
'CR's in the win32 copy so the cygwin vim could use them, since the
cygwin vim was sensitive to CR's while the Win32 vim didn't care which
was used. This worked as long as both vims were in sync, version
wise...which was true...for a long while, but of course that changed
creating its own set of minor complications....
The bigger changes came in adapting to Win7.
First prob that hit me in a bad way: Cygwin didn't know about
symlinks on Win7. It just followed win7 symlinks as though they were
real hard links...which meant directory pointers, placed by Win7 to
'common locations' in a users's home dir to default places like the
system menu, and all-users dir would automatically be followed by
cygwin and processed as though they were local to your user dir.
This was bad enough for things like 'find' or anything based on a
recursive dir search, but disastrous when you were using rm -r in any
dir, as winsymlinks could point anywhere -- as in one case -- to the
".recycle bin", where it proceeded to walk that and everthing in the
recycle bin, which lead it up to the other places... icky icky
icky.... (this was ~Oct-Nov/Dec of 2009 when it first came out).
Had to reinstall Win7 about 3-4 times due to various problems in
this time frame - some my fault for not knowing how things had changed,
some cygwin's fault for not knowing how things had changed (symlink
thing, mostly, though neither it nor I knew that C:\windows\system32 in
cygwin != C:\windows\system32 in Explorer (among other 'surprises')...,
and some by Win7 just for spite (system restore, failing but instead of
leaving things "unchanged" like it claimed, it had wiped out about 1/3
of the system files)....
I gave up on using cygwin entirely for almost a year due to that problem -- eventually Cygwin caught up and knew enough to not follow them....but before that, the cyg-utils were dangerous on a Win7 (or even winXP) system -- just that symlinks on winXP in the form of hardlinks and 'linkd' weren't as commonly used. But similar features hve been on Win since
XP days, with a bit less flexibility.
Added to my original C:\Home\lindaw, I had:
C:\users\lindaw,
then,
C:\users\HOMEDOMAIN.lindaw
then 3 more additions:
//HOMEDOMAIN/lindaw
the 'evil'
h:\\
(network drive pointing to my linux home dir as HOME DOMAIN returned
/home/lindaw as my
'HOME', which was exported by samba as //HOMEDOMAIN/lindaw (%D/%U in
smb.conf) which caused some confusion until I realized that completely
sharing
home dirs on a linux sys and windows sys wasn't a great idea...
So finally[sic], sorry, mean 'most recently':
i:\\
The root of the roaming profile for WinXP, and Win7 as sometimes
seen when a prog finds my homedir by patching together
HOMEDRIVE+HOMEPATH (there is no HOME on Win).
To those, 5 paths, had to make sure .vim/_vim and similar
incompatbilitys ALSO played
nice together, so that's about 10 combinations...
It DID work...
But lately, win7 and samba threw 2 more curve balls at me:
Sometimes randomly, windows would set my home to be:
C:\users\lindaw
and, other times:
i:\\
It depended on whether or not (I think) it managed to connect to the
login server and read it's description of my 'home' dir. My home
domain server has my home dir as //HomeDom/lindaw.
It maps the login drive to drive i: and login path to \, -- when I
login, windows usually has drive I mounted and pointing at
//homedom/lindaw. Vim like to use DOS path rather than UNC
paths...just like it used to favor 8-bit local charsets instead of
Unicode, it's a bit slow on the uptake...
If I start gvim from Bash, in cygwin, then it knows my HOME is
//HomeDom/lindaw,
If the login server can't be contacted when I initially login, then
C:\users\lindaw gets set for my
Homedrive (C:) and path (\users\lindaw), but if it can, it will be the
i:\\ value.
In either case, if I start it from the shell (bash), it has HOME set
from the Cygenv which does the
right thing and reads it from the entry for the user's home dir which
it got from the domain controller,
(i.e. the //Homedom/lindaw)... the diff between //homeDom/lindaw and
i:\\ is nil.
However, if windows was slow to talk to a login server, it doesn't
have HOMEDRIVE and HOMEPATH set right, so Gvim gets it wrong...I'm not
sure if this change is propagated down after
I login, to explorer login shell or not, or if my explorer shell gets
restarted.... But sometimes after being logged in for a while my Home
will change from C:\users\lindaw to the network...
Actually the above is slightly simplified...since If I login with a
local signon, then I get C:\users\lindaw, but if I use my domain signon
(the usually case unless having problems with domain controller and
network), then home is C:\users\lindaw.HomeDom . So that's another
path --
and that one can alternate with the same network path that the local
user id has.
So I have about 5 different paths...yep, just checked above...its
consistent counting from source or origins...amazing! ;-), all of which
need to have some consistency and duplication for windows,
BUT I can't use the same vimfile between linux and Win32 Gvim for
multiple reasons.....
It has to be different because, for one, the colors on the Gvim on
windows are hard coded-broken not to match colors as defined under any
other platform! ANOTHER MSDOS special -- limiting Gvim's colors to 16
colors -- not for all of them, but some, there's been a hard coded
value that may have been fixed in recent patches (Come 0n, lets hear a
protest about how this will break compatibility for someone who was
relying on the broken, MS-DOS era behavior!)...
So those are nixed until that is patched at least... But can use
some of the files... Maybe color files can't be the same, but .vimrc
can....most syntax, and macros, etc. But for .gvimrc, -- anther
problem area....
Font syntax:
set guifont=Lucida_Console:h11 (Windows)
set guifont=Lucida\ Console\ 13 (X11 - from Cygwin or my linux box)
Interestingly, the above 2 fonts are the same size on my Win display
...so even the sizes
can't be the same!
So I need to keep some file separate some the same, and some linked
to dulicates for the same broken 8.3 name compat that's all but
dead...even MS doesn't support FAT12/16/32 in their newer OS's...
Right now I look at .vimrc ... currently get stuck in my appdir,
/users/lindaw.Homedom, and the .vimrc ... seems ancient -- not the same
as most current on the net....
So depends on how I start vim (same vim version), when I start it,
which version (linux, Win32Gvim, Cygwin gvim....etc...)
WAY too many variables and to add the randomness ... that was the
iceing on the cake.
So explain to me why: 1) vim can't always look for
(.vimrc/.gvimrc/.vim) first, before looking for
_equiv/vimfiles)...AND if it finds a "." file, then it no longer looks
for _vim the rest of that session -- and doesn't look for vimfiles, but
looks for .vim?
How will anyone get duplicate anything?
How will it break people's compat?
You think what I have to go through (I have dealt with a buttload of
workarounds, but getting
past my point of just rolling over and dealing...which is why I'm
speaking up now!)....should be a normal user experience?
People should need these headaches to get things to play nice
together?
Somethings can't be helped...OS diffs...I understand, though
shim+abstraction layers can go
a long way toward solving that too. But I'm just asking the Win
platform to behave the same as the non-Win platform.... They BOTH look
for .vimrc and _vimrc...just in different orders (why?)
Why not have similiar behavior for .vim/vimfiles? (for that matter
why were colors ever hard coded to be different on the MSDOS version
from standard colors on every other platform?!)....
linda who has is going over the edge...iieeeeee
Gary Johnson
On 2011-10-25, Linda W wrote:
> But lately, win7 and samba threw 2 more curve balls at me:
>
> Sometimes randomly, windows would set my home to be:
>
> C:\users\lindaw
>
> and, other times:
>
> i:\\
>
> It depended on whether or not (I think) it managed to connect to the login
> server and read it's description of my 'home' dir. My home domain server has
> my home dir as //HomeDom/lindaw.
> It maps the login drive to drive i: and login path to \, -- when I login,
> windows usually has drive I mounted and pointing at //homedom/lindaw. Vim like
> to use DOS path rather than UNC paths...just like it used to favor 8-bit local
> charsets instead of Unicode, it's a bit slow on the uptake...
I don't know where you get that. Vim 7.3.138 on Windows XP seems to
handle UNCs and DOS paths equally well for me.
[Lots more problems not of Vim's making.]
> So I have about 5 different paths...yep, just checked above...its consistent
> counting from source or origins...amazing! ;-), all of which need to have some
> consistency and duplication for windows,
> BUT I can't use the same vimfile between linux and Win32 Gvim for multiple
> reasons.....
Nonsense. There is no reason one vimrc file cannot be used for
both.
> It has to be different because, for one, the colors on the Gvim on windows are
> hard coded-broken not to match colors as defined under any other platform!
I have one color scheme file I use on both Windows and Linux, for
both gvim and vim. I have my colors set pretty much the same for
all platforms, but there are limitations imposed by the platforms.
The hard part is that the palette is determined by the platform that
the display is running on, not the platform that Vim is running on,
and Vim can only reliably determine the latter, so some settings are
determined heuristically. That's a minor problem and not one that
Vim can solve.
My color scheme file is structured like this:
" Set Background
" Set Defaults
" Common Monochromatic Terminal Settings
" Common Color Terminal Settings
if &t_Co == 8
" PuTTY Color Settings
endif
if exists("$COLORTERM") && $COLORTERM == "gnome-terminal"
" Color GNOME Terminal Settings
endif
" Common GUI Settings
if has("gui_gtk2")
" GTK 2 (GNOME) GUI Settings
endif
if has("gui_win32")
" Windows GUI Settings
endif
Too complicated? Fine, but don't complain that you can't get the
colors you want. For me, it just works and solves the problem of a
consistent color scheme everywhere.
> So those are nixed until that is patched at least... But can use some of the
> files... Maybe color files can't be the same, but .vimrc can....most syntax,
> and macros, etc. But for .gvimrc, -- anther problem area....
>
> Font syntax:
>
> set guifont=Lucida_Console:h11 (Windows)
> set guifont=Lucida\ Console\ 13 (X11 - from Cygwin or my linux box)
>
> Interestingly, the above 2 fonts are the same size on my Win display ...so even
> the sizes
> can't be the same!
This is a feature/limitation of the graphics system, not of Vim.
Tony seems to be the resident expert on this, but here's what I have
in my .vimrc/_vimrc:
if has("gui_running")
if has("gui_gtk2")
set guifont=Monospace\ 12
elseif has("x11")
set guifont=*-lucidatypewriter-medium-r-normal-*-*-180-*-*-m-*-*
elseif has("gui_win32")
set guifont=Courier_New:h10:cANSI
endif
endif
Because Windows users expect[ed] Vim to read _vimrc and Unix users
expect[ed] Vim to read .vimrc. If both happen to be in a user's
$HOME directory, Vim reads the one that it thinks the user expects
it to read. That makes sense to me. If only one of those two
files--either one--is in a user's $HOME directory, Vim reads that
one.
This behavior is only a problem to a user has both .vimrc and _vimrc
in their $HOME directory, the contents of the two files are
different, and the user expects Vim to read the one whose name is
not the one normally found on that system.
> Why not have similiar behavior for .vim/vimfiles? (for that matter why were
> colors ever hard coded to be different on the MSDOS version from standard
> colors on every other platform?!)....
Computer operating systems and environments are not consistent.
That's just the way it is. Vim gives you the means to adapt its
configuration to the environment, and more thoroughly than any other
program I know of.
I have Vim installed on Windows XP Professional, Windows XP Home,
Fedora 11, Fedora 14, Ubuntu 8.04 and Ubuntu 10.04, all sharing a
common set of configuration files originally written for HP-UX and
Solaris. My Vim instances all look and behave pretty much the same,
whether gvim or vim, on Windows or Linux. That it works so well is
a tribute to Bram and his insistence on consistency across platforms
and revisions.
Given all I've read from you, the naming of Vim's configuration
files is the very least of your problems, and it shouldn't be
affecting your ability to solve the others.
You've made your pitch for changing those names. It's now up to
Bram to decide whether the change would be a net benefit. In the
mean time, if the naming thing is really holding you up, Ben and I
have given you a solution. I'd suggest that you implement it and
move on to the next problem.
As for this being a universal problem screaming to be solved: I
don't recall hearing of anyone else having a real problem with this.
If you'd like help with your other problems, choose one, explain it
here, and I'm sure we can come up with some solutions, or explain to
you why it can't be solved.
Regards,
Gary
Linda W
` Ben Fritz wrote:
On Oct 25, 11:39 am, Linda W <v...@tlinx.org> wrote:Ben Fritz wrote:On Oct 25, 2:52 am, Linda W<v...@tlinx.org>wrote: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.But, unlike the .vimrc/.gvimrc, any number of directories can be in the runtimepath. There is only one .vimrc.Sorry, but you lost me. you can have any number of dirs named .vim? Huh? isn't ".vim" searched for in the same locations as .vimrc/.gvimrc?? I wasn't asked for it to be searched for in the runtime path. I am under (perhaps, the "mis-"), that .vim as a dir was searched for along for, or in the same way as .vimrc/.gvimrc and the breakage occurred because on Windows it uses a 15-20'yro restriction on filenames that applied to FAT to use another yet another special name for the sake of FAT12/16 & MS-DOS. I'm not talking about the 'VIMRUNFILES' where vim finds its own runfiles...but the USER rules that are read along side the "built-in" vimruntime dir files. ----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.You probably won't have multiple .vim files. I'm not suggesting that.
What I mean, is that while Vim only finds and reads a single .vimrc file, then stops, this is NOT what happens with the folders in "vimfiles". The ONLY reason Vim reads the contents of $HOME/vimfiles, is because by default, the 'runtimepath' option is: Unix: "$HOME/.vim, $VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after, $HOME/.vim/after" Amiga: "home:vimfiles, $VIM/vimfiles,$VIMRUNTIME, $VIM/vimfiles/after, home:vimfiles/after" PC, OS/2: "$HOME/vimfiles, $VIM/vimfiles, $VIMRUNTIME, $VIM/vimfiles/after, $HOME/vimfiles/after" Macintosh: "$VIM:vimfiles, $VIMRUNTIME, $VIM:vimfiles:after" RISC-OS: "Choices:vimfiles, $VIMRUNTIME, Choices:vimfiles/after" VMS: "sys$login:vimfiles, $VIM/vimfiles, $VIMRUNTIME,$VIM/vimfiles/after, sys$login:vimfiles/after" Here, I assume "PC" refers to Windows. I observe my own runtime path (which I do not touch) matches this assumption.
Ok .. I took the liberty of grouping the lines by type. local-before, VIM standard, and local-after
I Can say one thing for certain. The PC Version hasn't been a correct
path since Win98 (if then).
HOME isn't a a system defined var. HOMEDRIVE/HOMEPATH, yes...but not
HOME. So unless someone set it, it won't it won't exist.
Vim is using an undefined variable as PC's come from the factory..
Now you are complaining because I want to use a standard dirname off of
a dir that, by default, doesn't exist?
You can say I should give up...Vim is going to adhear to it's 20 year
old roots and standards and not change, but ... they said that about
Unicode when I fought that battle and when I asked for variable width
spacing in vim -- I was told it couldn't be done. Bram just wasn't
capable.
Bull.
It's not on win32, (one of the last places to get open-source
support due to MS's hostility (screw them)), but it is on Linux, and
cygwin's gvim. , it's even on linux's tty based vim.
$HOME is undefined on Windows. THAT might be one source of the problem.
It is NOT a system variable but has to be set by each person on their system.
If they want to use standards, then %HOMEDRIVE%%HOMEPATH% is the var to use. But $HOME doesn't exist unless the user has defined it (directly or by installing some piece of software that does -- like cygwin...but then only for they launch from cygwin -- cygwin doesn't set home in the outside windows environment.
So It's ALREADY the case, that most users won't even know where to
set HOME .. just like someone
else said it's unlikely they will hit a command line, I bet even fewer
know how to set permanent environment variables for all users or
themselves... It's hardly difficult in the system properties, but if
they are they type that never touches a command line, what is the %
likelihood that they will know where to change system properties..?
So looking for .vim in $HOME (for example) would be perfect, because you already have to have system admin knowledge on some level to have set it.
This is by design. It allows users to very easily override anything in plugins or VIMRUNTIME files, and/or install plugins for use on a system at large which every user need not install but can probably use.
Looks pretty messed up and inconsistent.
Now, you're proposing that Windows is inconsistent, because it doesn't check the $HOME/.vim directory. I would counter that it is truly Unix that is inconsistent.
Out of all the systems with default values for 'runtimepath' listed, Unix is the only one which uses .vim. Every other system, and indeed Unix itself for the non-user-specific files, use "vimfiles". So, if any change is made, logically it would be to default Unix Vim to using $HOME/vimfiles, rather than defaulting Windows to use $HOME/.vim.
That's not the case on Windows, nor likely MAC...
If the file system supports it -- go with the standard.
And I'm sure we can safely assume that Unix users everywhere would be angry for years if Bram decided one day to use vimfiles rather than .vim for the default Unix Vim config.
As opposed to making Win and Mac more compat, which would piss people off how?
Especially since $HOME isn't set in any version of widows since at least XP. Might have
been set in Win98 and before. But that's what I'm talking about...the standards it is following were for 15 years ago. They aren't for today's OS's.
pansz
> But I asked how it would be incompat if it looked for .vim, if found, then
> don't look for vimfiles.?
You always have multiple runtimepath, at least you have ~/.vim and
/usr/share/vim/vim73 as the runtimepath.
If you ignore any others after looked for ~/.vim, then the system path
would be ignored.
Jürgen Krämer
Hi,
Ben Fritz wrote:
>
> This is pretty much what I was proposing. I would extend it further.
> Something like this could be placed in vimrc_example.vim, which AFAIK
> is sourced by default in a brand-new Windows installation:
>
> " check for $HOME/.vim existing INSTEAD of $HOME/vimfiles, in case Vim
> users from Unix aren't paying attention
> if has("win32") && isdirectory(expand("$HOME")."/.vim") && !
> isdirectory(expand("$HOME")."/vimfiles")
> let &rtp = "$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/
> after,$HOME/.vim/after"
> endif
>
> (still untested...potentially as Gary says the RHS needs to be
> expanded)
no, there's no need for expansion. As I wrote in another mail -- which
Linda chose to ignore and preferred to go on ranting ;-) -- I have
set runtimepath=~/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after,~/.vim/after
in my .vimrc on Windows and this works.
Jürgen Krämer
Hi,
Linda W wrote:
>
> I Can say one thing for certain. The PC Version hasn't been a correct
> path since Win98 (if then).
>
> HOME isn't a a system defined var. HOMEDRIVE/HOMEPATH, yes...but not
> HOME. So unless someone set it, it won't it won't exist.
there's no need for the user to set $HOME on Windows. Vim does it by
itself if $HOME is not already defined. Do a
:help version6
and search for HOMEDRIVE.
Marko Mahnič
I use the following setup which works fine between Win7 and Linux. I
suppose it should work on other systems, too.
The Vim files are in the directory ~/myvimfiles. This directory is
copied between different systems. Vim settings are in the following
files:
~/myvimfiles/vimrc
~/myvimfiles/gvimrc
There are no dots nor underscores in the filenames. This makes the
files usable on any system.
To load the config files I have these files in ~/:
" file: ~/.vimrc or $HOME/_vimrc
exec 'source ' . resolve(expand("<sfile>:p:h")) . '/myvimfiles/
vimrc'
" file: ~/.gvimrc or $HOME/_gvimrc
exec 'source ' . resolve(expand("<sfile>:p:h")) . '/myvimfiles/
gvimrc'
The runtimepath is modified in myfiles/vimrc like this:
let s:thisfile = resolve(expand('<sfile>'))
let $MYVIMDIR = fnamemodify(s:thisfile, ':p:h')
let s:paths = split(&rtp, ',')
let i = index(s:paths, $MYVIMDIR)
if i < 0
call insert(s:paths, $MYVIMDIR, 0)
let &rtp = join(s:paths, ',')
endif
This sets the RTP correctly when the contents of ~/.vimrc is set as
above and also when it is a symlink to ~/myvimfiles/vimrc.
For machine-dependent settings (eg. the root directories of projects,
notes, etc.) I use hostname() to load those settings. Note that this
might not work if the string returned by hostname contains characters
that are not valid in filenames:
let s:configdir=$MYVIMDIR . '/config'
let s:hostfile = s:configdir . '/hostrc/' . hostname() . '.vim'
if filereadable(s:hostfile)
exec 'source ' . s:hostfile
endif
The variable $MYVIMDIR is also used to manage plugins in a pathogen-
like environment: the plugins are downloaded to the directory
s:bundledir = $MYVIMDIR . '/bundles'.
Marko
Marko Mahnič
>
> The runtimepath is modified in myfiles/vimrc like this:
Gary Johnson
Shouldn't there be a
call add(s:paths, $MYVIMDIR . "/after")
here?
> > let &rtp = join(s:paths, ',')
> > endif
Regards,
Gary
Ben Fritz
On Oct 25, 4:58 pm, Linda W <v...@tlinx.org> wrote:
>
>
> So explain to me why: 1) vim can't always look for (.vimrc/.gvimrc/.vim) first, before looking for
> _equiv/vimfiles)...AND if it finds a "." file, then it no longer looks for _vim the rest of that session -- and doesn't look for vimfiles, but looks for .vim?
>
systems implement exactly what you ask with very simple vimscript
which has already been posted in response to your rants.
2. By default, Vim does not look for .vim and stop, because that's not
how the runtimepath is supposed to work. BY DESIGN, THE ENTIRE
RUNTIMEPATH IS SEARCHED. Yes, some C code would be added to default
the runtimepath differently depending on whether a .vimrc or _vimrc is
found. But this is trivial to implement in vimscript so I doubt very
much it will happen.
Ben Fritz
completely breaks word wrapping (on the message and response) in the
google groups interface.
It seems to be the only email that does this.
http://groups.google.com/group/vim_use/msg/f7395e53c0a68c31
Please respond in plaintext, as per list policy.
On Oct 25, 8:23 pm, Linda W <v...@tlinx.org> wrote:
>
> Ok .. I took the liberty of grouping the lines by type. local-before, VIM standard, and local-after
>
after could be any number of separate directories. They need not (and
often ARE not) a single directory.
Pathogen is specifically designed to automatically add a bunch of
directories to "local-before" and "local-after." You also need not
have any of these types, it's just the default
convention Vim has adopted and the documentation all assumes.
>
> I Can say one thing for certain. The PC Version hasn't been a correct path since Win98 (if then).
>
>
> HOME isn't a a system defined var. HOMEDRIVE/HOMEPATH, yes...but not HOME. So unless someone set it, it won't it won't exist.
>
>
internally if not set, and yes, it uses HOMEDRIVE/HOMEPATH.
This is a non-issue.
> Vim is using an undefined variable as PC's come from the factory..
>
variable manually.
>
> Now you are complaining because I want to use a standard dirname off of a dir that, by default, doesn't exist?
>
defines by itself if it doesn't exist. And you can instruct Vim to do
just that with one :set command.
>
> You can say I should give up...Vim is going to adhear to it's 20 year old roots and standards and not change, but ... they said that about Unicode when I fought that battle
> and when I asked for variable width spacing in vim -- I was told it couldn't be done. Bram just wasn't capable.
which would need to be completely redone, basic commands like hjkl
would need to be re-thought, etc.
It's not an impossible change. It's a change with a HUGE impact, for
almost zero benefit except to a few people like yourself. Nobody with
the required knowledge of the Vim
source has the motivation to make such a huge change. Maybe with a
patch, including a lot of documentation updates, it might be
considered for Vim 8.x. Obviously I cannot
speak for Bram, but the sorts of changes required for variable-width
font in my opinion are WAY to complicated and WAY to intrusive to be
worth it without a mature and
well-tested patch.
>
> $HOME is undefined on Windows. THAT might be one source of the problem.
>
> It is NOT a system variable but has to be set by each person on their system.
>
HOMEPATH, if HOME itself is not set. Vim provides reading of HOME on
Windows:
a) for consistency with other systems
b) to allow users to override the default directories in YET ANOTHER
way
> If they want to use standards, then %HOMEDRIVE%%HOMEPATH% is the var to use. But $HOME doesn't exist unless the user has defined it (directly or by installing
> some piece of software that does -- like cygwin...but then only for they launch from cygwin -- cygwin doesn't set home in the outside windows environment.
>
> So It's ALREADY the case, that most users won't even know where to set HOME .. just like someone
> else said it's unlikely they will hit a command line, I bet even fewer know how to set permanent environment variables for all users or themselves...
> It's hardly difficult in the system properties, but if they are they type that never touches a command line, what is the % likelihood that they will know where to change
> system properties..?
>
> > Now, you're proposing that Windows is inconsistent, because it doesn't check the $HOME/.vim directory. I would counter that
> > it is truly Unix that is inconsistent.
> Oh? What other platforms try to use HOME?
Unix, Windows, and OS/2 use $HOME. Amiga uses "home:",.which I assume
is equivalent.
The others do not use $HOME, however they DO use "vimfiles", which was
the point I made initially.
> > Out of all the systems with default values for 'runtimepath' listed, Unix is the only one which uses .vim. Every other system, and indeed Unix itself for the non-user-specific
> > files, use "vimfiles". So, if any change is made, logically it would be to default Unix Vim to using $HOME/vimfiles, rather than defaulting Windows to use $HOME/.vim.
> That's because when vim was ported to them...all of them had more primitive file systems than what unix had at the time. Unix is OS that set the standard. vi was born
> there decades ago.
> That's not the case on Windows, nor likely MAC...
> If the file system supports it -- go with the standard.
"the standard" only on Unix-like systems, where ".vim" is hidden from
the user by default. And Unix itself
uses "vimfiles" for the system Vim config. If we should "go with the
standard" then why shouldn't Windows Vim default to using $HOMEDRIVE/
$HOMEPATH/Application Data or
"Local Settings" or whatever the default Windows app-specific config
directory is? Vim has already set a standard for Windows, and other
OSes. It's $HOME/vimfiles. Unix is
the weirdo here, and most users don't bat an eye.
> > And I'm sure we can safely assume that Unix users everywhere would be angry for years if Bram decided one day to use vimfiles rather than .vim for the default Unix Vim config.
> Especially since $HOME isn't set in any version of widows since at least XP. Might have
> been set in Win98 and before. But that's what I'm talking about...the standards it is following were for 15 years ago. They aren't for today's OS's.
is that you are asking for a change in a very basic configuration
setting. People have been using this setting
without complaint for years. Suddenly changing it for no reason, in
ways that would break systems currently in use, is going to cause
problems. I made the point that Unix is the
ONLY system Vim supports which defaults to using ".vim" instead of
vimfiles. Your logic was that we should change Windows to use ".vim"
for consistency. Using your logic, the
truly logical change to make "for consistency" would be to change Unix
to default to "vimfiles" rather than the other way around. And I think
it is obvious why that would be a bad
idea. I was attempting to infer that you should extrapolate and apply
the same reasoning to your proposed change.
And yes, systems will break. I assume that many people with a HOME
directory shared between Windows and Unix-like systems will have both
a .vim and a vimfiles directory,
with the knowledge that Windows will never look in .vim, and Unix will
never look in vimfiles, and therefore there has been no reason for
them to take the differing systems into account.
Have you tried the simple workaround of checking for .vim existing
without vimfiles and setting the runtimepath accordingly? Nobody else
seems to find a need for it. If it is useful
enough, maybe we can submit a patch to vimrc_example.vim. But I think
it would be a waste of time to change the C code and documentation.
Marko Mahnič
Thanks,
Marko
Linda W
you would only not look for 'vimfiles' in the user dir's where you found a ".vim"...
you'd still process the path normally. Just if you find a .vim then stop searching in that
dir and begin processing the next.
Ben Fritz
On Oct 26, 6:57 pm, Linda W <v...@tlinx.org> wrote:
> pansz wrote:On Wed, Oct 26, 2011 at 9:23 AM, Linda W<v...@tlinx.org>wrote:But I asked how it would be incompat if it looked for .vim, if found, then don't look for vimfiles.?You always have multiple runtimepath, at least you have ~/.vim and /usr/share/vim/vim73 as the runtimepath. If you ignore any others after looked for ~/.vim, then the system path would be ignored.---
> you'd still process the path normally. Just if you find a .vim then stop searching in that
> dir and begin processing the next.
You tell it exactly what directory or directories to use.
By default, you tell Vim to use ~/vimfiles on Windows, and ~/.vim on
Unix. There is no searching, no "if this directory exists use it for a
Vim config", or anything like that. Any directory in 'runtimepath'
which exists is used. Users could even use both .vim and vimfiles,
something like:
set runtimepath=$HOME/.vim,$HOME/vimfiles,$VIM/vimfiles,$VIMRUNTIME,
$VIM/vimfiles/after,$HOME/vimfiles/after,$HOME/.vim/after
Setting up a variable "if this directory exists, don't use this other
directory" would be a change to the very NATURE of the 'runtimepath'.
The correct solution to this problem, if people can agree there is a
problem at all, would be to set the value of 'runtimepath' based on
the presence/absence of a $HOME/.vim directory. While this can be done
internally in Vim's C code, setting a different default value based on
the presence/absence of such a directory, I think this would be even
more confusing than the current situation. I think the real solution
is the trivial vimscript snippet shared earlier, added to the very
beginning of a .vimrc:
if has("win32") && isdirectory(expand("$HOME")."/.vim") && !
isdirectory(expand("$HOME")."/vimfiles")
let &rtp = "$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/
after,$HOME/.vim/after"
endif
for the sake of people coming in from Unix.
I do note that the Vim installer (or at least, the Vim without Cream
installer I use most of the time) it specifically gives an option to
create a vimfiles directory for you. I would think this is already
hint enough, personally.
Tony Mechelynck
> 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
This is one of all those "Vim traditions" which remain because it is not
worth breaking upwards compatibility to change them.
On Unix-like systems, there is a tradition to put program config files
for all programs in a directory with a name starting with a period,
which would then be "hidden" by default.
On DOS-like systems, before LongFileNames were invented, you couldn't
have a file- or directory-name starting with a period. So ~/vimfiles was
established where ~/.vim was the Unix tradition, and also ~/_vimrc and
~/_gvimrc where Unix would use ~/.vimrc and ~/.gvimrc.
On systems with LongFileNames, Windows Vim still looks for .vimrc when
it couldn't find ~/_vimrc, and for ~/.gvimrc when it couldn't find
~/_gvimrc. Conversely on Unix. This is a courtesy to double-boot etc.
users. But these are just one file each, and read only once each, at
startup. Adding an additional 'runtimepath' directory might make every
runtime script lookup more sluggish, for little advantage.
Platform-hopping Vim users should know (and, like everything else about
Vim, it is documented, in this case at :help 'runtimepath') that user
scripts are placed under ~/.vim/ on Unix and under ~/vimfiles/ on
Windows. Beware though, that _system-wide_ scripts not distributed with
Vim belong under $VIM/vimfiles on all systems, even on Unix.
On a double-boot system, where soft links are easier to manage from the
Unix side, and where the Linux kernel can read vfat filesystems but the
Windows kernel cannot make head or tail of an ext2, ext3, ext4 or reiser
filesystem, you could have your /etc/fstab mount your vfat partition
somewhere, and then make ~/.vim on the Unix side a soft link to what
would be seen as ~/vimfiles when running on the Windows side. In that
case, don't forget that Windows Vim can source Unix-format scripts (with
LF-only ends of lines) but Unix vim cannot source Dos-format scripts
(with CR-LF), so all those "common" scripts would need to use Unix
'fileformat'.
Best regards,
Tony.
--
I love this fucking University, and this University loves fucking me.
Linda W
>
> On Oct 26, 6:57 pm, Linda W <v...@tlinx.org> wrote:
>> pansz wrote:On Wed, Oct 26, 2011 at 9:23 AM, Linda
W<v...@tlinx.org>wrote:But I asked how it would be incompat if it looked
for .vim, if found, then don't look for vimfiles.?You always have
multiple runtimepath, at least you have ~/.vim and /usr/share/vim/vim73
as the runtimepath. If you ignore any others after looked for ~/.vim,
then the system path would be ignored.---
>> you would only not look for 'vimfiles' in the user dir's where
you found a ".vim"...
>> you'd still process the path normally. Just if you find a .vim
then stop searching in that
>> dir and begin processing the next.
>
> Vim doesn't "search" for .vim or vimfiles.
>
> You tell it exactly what directory or directories to use.
Geez...how does a file lookup work?
I thought inherently, had to open the directories that you specified,
and retrieve
the entries in the directory and see if any of them match what you are
looking
for.
Normally, this behavior is call searching. Perhaps you think matches with
filenames occurs by magic??
>
> By default, you tell Vim to use ~/vimfiles on Windows, and ~/.vim on
> Unix.
You do?
I didn't say anything or tell my vim anything. Seems like it came
preconfigured to
do it's own thing. Are you saying there are no default paths that VIM
searches for
it's support files along?
That's not consistent with the vim help files.
> There is no searching, no "if this directory exists use it for a
> Vim config", or anything like that. Any directory in 'runtimepath'
> which exists is used. Users could even use both .vim and vimfiles,
> something like:
>
> set runtimepath=$HOME/.vim,$HOME/vimfiles,$VIM/vimfiles,$VIMRUNTIME,
> $VIM/vimfiles/after,$HOME/vimfiles/after,$HOME/.vim/after
----
USERS could do that...but maybe users don't alter the defaults because
everytime they go to a new system that isn't setup that way, something
will break.
Setting the default 1 time in VIM is infintely better than all the
1000's of hours
wasted by people -- JUST on this list, in developing workarounds for
this behavior.
If it was fixed in 1 place, in vim, that would save 1000 likely 100's of
thousands
of people's time, both in the present and the future.
That people want users to have vim be less compatible and harder to use
simply
make it clear that those people just want vim to never grow -- the
generally accepted
opposite of which, is 'die'.
Those people have no place in voicing their whiny opinions for people
who want to see
things improved.
I remember a big hoopla about unicode support when I asked for that --
and support
for multi-width charsets. I was told it would never be done -- and I
should just
accept that that was the way it was. Except both work on linux (both
vim and gvim),
and on cygwin gvim. (But not on Windows gvim...which is where I asked
for it in the
first place)...but on a tty window like 'SecureTTY' logged into a linux
box, it is supported.
So no one can claim GVIM can't support it NOR that it can't support it
because it fixed
with text, nor any of the traditional blowhard reasons as other progs do
and so does vim
just not on Windows yet.
>
> Setting up a variable "if this directory exists, don't use this other
> directory" would be a change to the very NATURE of the 'runtimepath'.
----
You ignoramus! You didn't read what **you** quoted above?
QUOTE:
you would only ***not*** look for 'vimfiles' in the ***user** dir's
where
you found a ".vim"... you'd still process the path normally.
Just if you find a .vim then stop searching in that dir and begin
processing
the next.
>
> The correct solution to this problem, if people can agree there is a
> problem at all, would be to set the value of 'runtimepath' based on
> the presence/absence of a $HOME/.vim directory.
----
you could do that.
Or you could just look for both in any order and once you found one,
don't look for
the other in that dir, then continue processing.
Or you could look for .vim first (my pref, but either would work),
as in the specification
on the reference machine/architecture.
> While this can be done
> internally in Vim's C code, setting a different default value based on
> the presence/absence of such a directory, I think this would be even
> more confusing than the current situation. I think the real solution
> is the trivial vimscript snippet shared earlier, added to the very
> beginning of a .vimrc:
>
> if has("win32") && isdirectory(expand("$HOME")."/.vim") && !
> isdirectory(expand("$HOME")."/vimfiles")
> let &rtp = "$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/
> after,$HOME/.vim/after"
> endif
>
> This could even be part of the default _vimrc installed on Windows,
> for the sake of people coming in from Unix.
>
> I do note that the Vim installer (or at least, the Vim without Cream
> installer I use most of the time) it specifically gives an option to
> create a vimfiles directory for you. I would think this is already
> hint enough, personally.
---
I didn't get a hint...
I just have a pre-existing .vimrc file that worked with cygwin which I
got from
my pre-existing setup on linux, which was dervived from my preexisting
setting
on Irix, circa 1994-1995, which got it's roots from SunOS's VI, before
that...etc.etc...
Now Win comes along and break compatibility -- and for what reason?
IT MAY have been necessary when FAT12/16 was the primary file system,
but not today and it's been along time since those file systems were
primary,
and you don't even have the option to format with them in Win7
(NTFS/exfat)...
Of course, as someone pointed out...back in the version6, era, a
slight footnote
pointed out that that a correction was needed (how long ago did V6 come
out?),
as HOME wasn't always set -- (not unless they had a sysadmin who set it
up, or
they themselves set it up). But the documentation referenced above,
was never updated
to clarify that vim uses HOMEDRIVE/HOMEDIR that it gets from Windows to
create/
synthesize HOME (unless the user pre-creates it in their ENV)...
Linda W
> On 13/10/11 01:47, Linda W 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.
>>
> Platform-hopping Vim users should know
---
Why?
Someone else said users couldn't be troubled with a command line,
so why expect them to now how to platform hop when vim/gvim works the same
most of the time, but when they goto non-cygwin win32, it fails?
Like that's user friendly?
(and, like everything else about
> Vim, it is documented,
---
Just because because bugs, deaths and taxes
are documented doesn't make them all 'fine and dandy'. \
in this case at :help 'runtimepath') that user
> scripts are placed under ~/.vim/ on Unix and under ~/vimfiles/ on
> Windows. Beware though, that _system-wide_ scripts not distributed with
> Vim belong under $VIM/vimfiles on all systems, even on Unix.
Right...and $VIM is set by MS to what? Nice irrelevant point.
>
> On a double-boot system, where soft links are easier to manage from the
> Unix side, and where the Linux kernel can read vfat filesystems but the
> Windows kernel cannot make head or tail of an ext2, ext3, ext4 or reiser
> filesystem, you could have your /etc/fstab mount your vfat partition
> somewhere, and then make ~/.vim on the Unix side a soft link to what
> would be seen as ~/vimfiles when running on the Windows side. In that
> case, don't forget that Windows Vim can source Unix-format scripts (with
> LF-only ends of lines) but Unix vim cannot source Dos-format scripts
> (with CR-LF), so all those "common" scripts would need to use Unix
> 'fileformat'.
--
?? and this is an issue how? that's easily set in a .vimrc file
by a 1-liner.
It's only on a new installation of vim that bugs crop up because
the defaults are broken.
You wanna stay compat..fine...
then...
>> Vim also doesn't seem to find
>
> This is one of all those "Vim traditions" which remain because it is not
> worth breaking upwards compatibility to change them.
---
How would it break...
No one has give a case where breakage would occur with the algorithm I
specified...
> On systems with LongFileNames, Windows Vim still looks for .vimrc when
> it couldn't find ~/_vimrc, and for ~/.gvimrc when it couldn't find
> ~/_gvimrc.
Bingo...
So just do the same with .vim.. "Vim lookes ffor vimfiles in 'dirX, but if
it doesn't find them, then it looks for ".vim"...
Well gee, isn't that such a difficult proposition?
And HOW does this the sky to fall in? I've asked that at least 4 times
now and people keep coming back with (if you find .vim stop
searching?...that won't work...) I never suggested that.
It's pretty obvious when multiple people have to make things up that are
blatantly false lies, it becomes clear they are trying to spread
propaganda.
They have an anti-user friendly agenda. They are putting themselves
first. Looking for both doesn't create harm, it creates compatiblity so
people don't have to keep reinventing workarounds like many have here.
Thousands of hours have, easily, been wasted by Vim not being ported
to new features until YEARS later...unicode was an example that took at
least 5 years longer than was comfortable. All the while I was told it
would never happen. Because Vim wasn't designed for that.
People...you are just stupid if you believe "the way a program is" means
you have to accept it. Programs didn't exist 60 years ago. We create
them -- there is NO essential nature about how a program is that one must
accept. It's a synthetic-manmade creation. It's not like 'oh gee, I
don't like that rocks are hard, or water is wet or gravity sucks, and I
want it changed... how programs are AREN'T natural laws. they are
arbitrary decisions made at a given point in time based on conditions at
that time. The only things that don't adapt to their environment -- dead
things.
If you believe vim can't change, then you believe it is dead.
>
Ben Fritz
us. Take you anger and personal attacks to a blog or something if you
want to insist on being so confrontational.
You have been told specific reason why your idea is a bad one. It will
change Vim to act in ways that existing documentation (within Vim,
within published books, and on the internet) does not reflect, current
users will not expect, and will do unexpected things on systems with
both .vim and vimfiles.
You have stated several times that you expect the .vim/vimfiles search
to work the same way as .vimrc/_vimrc search, and it was explained to
you that .vim/vimfiles is conceptually different from the .vimrc.
The .vimrc is sourced once and then Vim is done with it. .vim/vimfiles
is by default on the runtimepath, which Vim consults again and again
throughout program execution. A user option explicitly specifies which
directories are checked, and in which order. There is no "stop if this
directory doesn't exist" and such a condition would break from the way
the runtimepath works now. By comparison, .vimrc is one of several
specific file names Vim checks, which is not configurable, and Vim
will automatically stop when it finds ONE of them.
Unlike the .vimrc, EVERY time Vim needs something from the
runtimepath, it consults the option before checking every directory
within the option. Putting some logic external to the runtimepath to
check for the existence of .vim/vimfiles before proceeding would be
very confusing and make the 'runtimepath' option less useful. As
mentioned, the existence of .vim/vimfiles could be consulted before
defaulting 'runtimepath' to some value, this may be acceptable. Make a
patch and submit it to vim_dev and see where it goes instead of
whining and namecalling.
I'm done with this thread. I know I have not responded to many of your
points. Some of them because I feel they have been answered already,
but most of them because I would need to again read through your
jumbled, hard-to-read post, including all the insults and personal
attacks, in order to find them.
Respond if you must to get the last word in, but I suggest you shut up
and write a patch if you want any results.
Linda W
` Ben Fritz wrote:
> Linda, you cannot expect anyone to listen to you if you keep insulting
> us. Take you anger and personal attacks to a blog or something if you
> want to insist on being so confrontational.
>
----
Insulting...I used a word 'ignoramus' once, That's the only insult
I consciously
used because the write claimed I said 'x', when right above where he
wrote that,
he quoted me and that's NOT what it said.
I think that was um...rather 'light' as far as insults go...
seriously...so chill.
> You have been told specific reason why your idea is a bad one.I
I've been told why someone *thinks* it is bad. and I responded on how
to get around
the problem. So far, no one seems interested in solving the problem --
only defending
the broken status quo. Am I wrong? Who else here is interested in
solving the problem
so 100 of 1000's of vim users past and future won't have to write odd
and quirky code
to check for different paths on every vim they go that are all incompat
and **attempt***
to use links -- problem is that links cause problems with windows
interacting with linux/unix.
They aren't stable and safe.
If you put a symlink on linux, windows will see it as a hardlink. That
means any file copies will
go through it.
I have 2 user-profiles on my system 1-local and 1 domain. There
are some things
(most things) that I want to share between them. BOTH of them are
roaming profiles...
Adobe, for example puts their help text in the users local roaming
profile -- all 2.2GB of it.
This means it gets stored into each user's roaming profile.
Syncrhonized on login/logoff.
Just trying to safe disk space and use only 1 shared copy -- it still
will reference the login's
profile through the symlinks and have seen it go both ways .. my "local
copy" of adobe, being
read through my domain-profile's link as a 'domain copy' (which it
shouldn't do,l but I've seen it
happen), then written through a soft link (I no longer have such, after
I saw this behavior!)... to
the roaming profile of the local account ... i.e. overwriting the other
accounts values.
My roaming profiles end up getting copied from SERVER\home ->
C:\users\me, but depending on
whether or not I launch gvim from the shell in cygwin (in which case
home will be SERVER\home),
or from explorer, in which case home will be C:\users\me, **IF** I had
to be logged in with a 'saved'
copy of my profile, OR it will be "i:\", if it logged me in with my real
profile -- even though it still
will have copied my profile to C:\users\me, -- drive i:\ is the same dir
as SERVER\home which is
also the same dir that that the profile gets copied "to" and "from"...
Links in my home dir don't last long I start out with links from
vimfiles->.vim, then end up soem sync
with 2 separate copies...then I make changes in .vim, thinking that's
all I need to do...and it will be picked up by my cygwin vim, my win-vim
on both of my accounts on 2 different computers. -- they are
all windows accounts trying to share the same settings that have the
glue keep coming
Unglued....and it reverts to making copies of vimfiles at some point (or
just removing/losing the link
altogether.)... So if I never had a softlink or link from
vimfiles->.vim, there would be no copies
made, and things would just work.
> It will
> change Vim to act in ways that existing documentation (within Vim,
> within published books, and on the internet) does not reflect, current
> users will not expect, and will do unexpected things on systems with
> both .vim and vimfiles.
>
---
Every product has stuff published about it...there are books about
Bind version 5 and
perl 4 out there... But bind is up to version 8 or 9 now, and IT isn't
compatible. and perl
is up to 5.11 and it's not entirely compatible either.
You seem to think vim has to remain carved in stone. STOP THAT!
It's Not piece of
stone. It's called **SOFT** ware for a reason... it's mutable.
Changeable.
You are putting out reasons for nothing to ever change in vim...
Then you have no
worries -- you just never need to upgraded again.... Oh,.. you want 'X'
fixed? Sorry someone
might be relying on that behavior...can't do that... You can't use that
excuse to block
progress -- or like I said, Vim, as a product/project is dead, and I
don't think Bram would agree
with that. Why don't we ask him -- does he plan on never making any
changes to vim that
would require documentation changes to any past published book?
If he does, well he's saying the project is done. If that's the case,
it would be nice to know
so the project can be forked and move on.
> You have stated several times that you expect the .vim/vimfiles search
> to work the same way as .vimrc/_vimrc search, and it was explained to
> you that .vim/vimfiles is conceptually different from the .vimrc.
>
No --- I said it once. and only once. (show me the quotes if you want
to be taken
seriously). I read the responses that it was one of the several
default locations
looked at by the current vim. I'm proposing we ***ADD*** one more,
(not take away any).
So there can be no conflict with current usage. No? Why would
someone have a .vim directory
now on windows, if it doesn't work? Makes no sense. OTOH....
> The .vimrc is sourced once and then Vim is done with it. .vim/vimfiles
> is by default on the runtimepath, which Vim consults again and again
> throughout program execution. A user option explicitly specifies which
> directories are checked, and in which order. There is no "stop if this
> directory doesn't exist" and such a condition would break from the way
> the runtimepath works now.
Are you saying it sits and spins and looks for vimfiles in the same dir
and never goes on?
I have never said to stop looking ALONG the REST of the RUNPATH. you
follow the runpath
just like you always have. You aren't getting what I am trying to say.
If you don't find vimfiles in $HOME, look for .vim just like if you
don't find _vimrc, it lookes for
.vimrc. There is no stop condition. Either that or you look for .vim
and if you don't find that you
llook for vimfiles. The "stop" condition is if you "find" "X" you
don't look for the other in that dir.
but you do go on to the next dir to look for another vimfiles dir.. and
note...I'm not suggesting
.vim for every dir. Not needed/wanted. Just the home dir. same as on
unix/linux.
So what breaks...describe a scenario where it breaks. If I don't have
.vim, it does the same as it does
now. If I DO have one, it reads that and then goes on to process
vimfiles in other directories. Just
NOT in that directory ($HOME) where it found the .vim.
I need you to give me a detailed reason why / how this is going to cause
problems for the
userbase and estimate the impact. It it 90% of the users will be hit
by problem? Or 50%, 10%.? or
maybe 1-2 individuals, but possibly ?
Oh...write a patch...are you saying that's all I need to do to get this
fixed?
Hmmm...
I do want to figure out how to build vim on my win machine....
Might be a good opportunity...
Tony Mechelynck
[...]
> If you put a symlink on linux, windows will see it as a hardlink. That
> means any file copies will
> go through it.
If you set a symlink on a Linux (ext2, ext3, ext4, reiser, etc.)
filesystem, Windows won't see it at all because it cannot read those
filesystems. I was the one who mentioned symlinks, I mentioned them in
the context of double-boot, not of Cygwin, and I explicitly mentioned
ext2, ext3, ext4 and reiser filesystems. So who's distorting whose words?
Regards,
Tony.
--
"We'll cross out that bridge when we come back to it later."
Linda W
> On 28/10/11 22:26, Linda W wrote:
> [...]
>> If you put a symlink on linux, windows will see it as a hardlink. That
>> means any file copies will
>> go through it.
> [...]
>
> If you set a symlink on a Linux (ext2, ext3, ext4, reiser, etc.)
> filesystem, Windows won't see it at all because it cannot read those
> filesystems. I was the one who mentioned symlinks, I mentioned them in
> the context of double-boot, not of Cygwin, and I explicitly mentioned
> ext2, ext3, ext4 and reiser filesystems. So who's distorting whose words?
----
I'm not distorting anyone's words.
I'm replying about things I've tried that don't work.
Various people (besides you) mentioned some sort of link either
on linux or on windows (both have types of symlinks, both have hardlinks).
Worse, Windows also has "explorer-only symlinks", (.lnk), which cygwin
calls "symlinks" [sic] and will create if you turn on 'winsymlinks',
instead the actual windows symlinks available in win7 (which do get
dumped and restored properly to a linux disk, but are plain files on a
linux disk containing 'SYMLINKD (I think the D is for Dirs) followed
by binary pointer data), BUT aren't usable if you have the dir mounted
as a NW file system...
I.e. I was saying there are no types of links that will work
for what people think they will . Most win32 progs will only
follow the new 'symlinks (or their older counterparts, 'junctions'/
reparse points.). Very few will follow the special .lnk's that are
created by explorer and cygwin's 'compatible'[sic] mode. None will
follow cygwin's symlinks, and none of those will propagate across a
network and work across a network.
So to all the people I didn't respond to who suggested
various forms of links...it's because, if you don't understand all the
different types of links across explorer-word, NTworld, unix world, cygwin
world, and how they all look and survive across a copy from one to the
other and how they look when mounted on a network fileshare, you can't
begin to understand a solution involving links.
Some where claiming they'd offered a solution, whey they just
didn't understand the problem. I'm way past that point. Changing a file
to be 'custom' to work around this problem won't work either, because
windows resets and loses some files, but the files will still exist as
".vim" on the network mount -- and that still gets copied back and forth
(part of the time/most of the time) on synching a profile). But none of
the solutions work with a 'fresh' version of vim when it falls into place
and can't pick up needed files by looking in standard locations because
they look for things in different orders under different names -- and they
can't be linked together because of the various reasons described above.
Which means they always end up being separete copies that end up needing
to be changed in about 8-10 different places...all to get around
some crap standard that was implemented for MSDOS. That people are
against updating for newer OS's that don't have the same features (or
limitations).
Linda W
Linda W wrote:
> Tony Mechelynck wrote:
>
>> On 28/10/11 22:26, Linda W wrote: [...]
>>> If you put a symlink on linux, windows will see it as a hardlink.
>>> That means any file copies will go through it.
>> [...]
>>
>> If you set a symlink on a Linux (ext2, ext3, ext4, reiser, etc.)
>> filesystem, Windows won't see it at all because it cannot read those
>> filesystems. I was the one who mentioned symlinks, I mentioned them
>> in the context of double-boot, not of Cygwin, and I explicitly
>> mentioned ext2, ext3, ext4 and reiser filesystems. So who's
>> distorting whose words?
>
> ---- I'm not distorting anyone's words.
>
> I'm replying about things I've tried that don't work.
==== Seeing as how I explained, *in depth*, how you were mistaken, just
like every other argument against my case -- (except for one, which
informed, me, and I adapted my solution to fit the new
information...)...
So I adapted my solution to the only real problem, and no one came
up with any reason why my solution wouldn't work (or the kept claiming I
said something OTHER than what I said -- which after the 3-4th time,
started to get me a bit miffed. And then suddenly I was the bad person
for having to repeat myself for the 3rd or 4th time to someone who just
quoted the correct version of what I said but were claiming in their
response that I said something else.
But it seems once that became clear, there were no more objections
or claims of incompatibility. There's always claims that things were
done some way in the past...but that's true about every piece of
software that has ever existed. That hasn't stopped new
versions/standards of C, Perl, shell, linux, Windows...I don't know of
any software that still is viable to the user community that doesn't
grow and change.
So does anyone want to take the unenviable position of why Vim should
stay stuck with 1980's standards when the rest of the world has moved
on?
It wasn't until Vim6, that Vim even realized that HOME had been yanked
out from underneath them, -- the rest of the world moved on.
now believe me -- I've been on the other side of these issues often as
well. Take a look at the bash archives from about a month or two ago
where the behavior of bash broken longstanding scripts.
BUT THERE...it did so for NO good reason. No one used the old feature
cuz they thought it was broken! -- turns out it wasn't so broken, and it
had been usable, so it was made broken in 4.1. to follow the new POSIX
spec, which, is incompatible with the old posix spec. Except that the
feature/mode we are talking about was about bash's NON-POSIX,
"user-friendly mode"....so there was NO reason, even following a broken
standard to have changed it. (change was made to "-e" option to exit
on any non-zero status from any simple or complex command whereas
before, it was to detect any non-zero exist from specifically, *simple
commands*, that weren't error checked, but by including complex
commands, this meant that calculations (let a=b-b), would cause an fatal
error exist because it calculations return the 'not' of their final
calculation thus the calculation ((0)) would return '1' (false),
That and another arbitrary change was made that made all function call
no longer take the same return params that 'exit' would return (despite
a functions return is supposed to be equivalent to a program's exist
code).
Thy are reversing that decision, and the jury is still out as to whether
or not he's going to break 14 years of posix compliance to go with the
new and improved standard that isn't compatible with the old (in an area
of bash that is an extension and not even covered under posix!)...
So I'm not someone to just for every change, and fight against stupid
changes, but you have to be willing to weight the cost of a change
versus the overall benefit .. not just against the inconvenience of a
single user. When you see MANY users coming up with hacks and
workarounds to get around design decisions that once were valid, but now
be costing people more time and effort to work around than it's worth to
keep ith those decisions -- at that point, it's time to be
**practical**, and go with what's going to cause the least effort for
ongoing maintenance and future people's usage.
That doesn't mean there might not be a one time conversion 'pain' to
some new format, but if the payoff is much greater down the line --
that's what you have to keep your keys on... Not peoples immediate
gratification or pain levels.
This isn't an issue I've brought up for the first time. It isn't an
issue I just started dealing with.
I've been dealing with cross-platform .vim files and .bash/.profile
programs since the 80's. Getting Xenix and HP/UX to be compat with
SunOS/SGI/and dos-unix-shell work-alikes. I've had more than 2 decade
of experience working around these things. But I recognize when a
design that might have been right at one point in time, now is well past
the time of needing to be changed.
People need to realize. Designs of software are NOT cut in Stone. As
long as Bran maintains a vi-compat mode, he's doing his bit to
maintain core compat with required standards. But software was designed
to be able to be flexibly improved as needs and standards changed.
But I wish you'd stop arguing against all change.
There are basic text editing functions I can't do in vim in fixed with
fonts, that I can do in a web'browser text box because Vim is stuck
using some old DOS era text boxmodel.
Simple adopting a new display library would open the new features...but
I'm sure I've talked this point to death, unless anyone sees any other
problems with my proposals (other than them coming from me!)... (I know
that's a fairly negative point that kills alot of my proposals due to my
scintillating personality... *cough*....*ahem*...I'm only trying to do
what's best for the most...)... and I'll change my stance on something
mid-stream given new information that requires change -- just as I did
in this discussion. I'm not 'stuck in one position. I'll adapt to
realities brought to my attention that need attention (and did).
My persuasive style sucks (thanks you mom and dad for rasing me with
socratic method!)...but I do try to get a pretty wide perspective.