Re: Please fix: make Windows Vim use same files as unix. No reason not to and it's confusing in mixed envirionments.

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.

What a mess!!     

Exactly!!!     A beautiful example and comment of WHY this bug NEEDS to be fixed.

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