First, I don't know what's wrong with this particular email, but it 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 <[email protected]> wrote: > > Ok .. I took the liberty of grouping the lines by type. local-before, VIM > standard, and local-after > That sounds about right. But keep in mind that local-before and local- 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. > > The Vim documentation tells you exactly how Vim determines HOME 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.. > So what? It defaults to something useful if the user has not set the variable manually. > > Now you are complaining because I want to use a standard dirname off of a dir > that, by default, doesn't exist? > No, you're trying to use a non-standard name off a dir which Vim 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. Nobody said it wasn't possible. They said Vim has an existing design 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. > False. Untrue. Vim automatically determines $HOME from HOMEDRIVE and 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. > And Vim already uses these variables, as stated several times before. > 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..? > They don't need to. See above. > > 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? If you read the list of defaults for 'runtimepath', you'd see that 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. So why is ".vim" automatically the standard? As far as I know, that is "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. > 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. Again, $HOME being set or not has very little to do with it. My point 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. -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
