> 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...
--
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