>
> 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<vim@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.
So it doesn't search the path you give it for filenames that might match?
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)...
--
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