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
>
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
No comments:
Post a Comment