On 2011-10-25, Linda W wrote:
> 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...
I don't know where you get that. Vim 7.3.138 on Windows XP seems to
handle UNCs and DOS paths equally well for me.
[Lots more problems not of Vim's making.]
> 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.....
Nonsense. There is no reason one vimrc file cannot be used for
both.
> 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!
I have one color scheme file I use on both Windows and Linux, for
both gvim and vim. I have my colors set pretty much the same for
all platforms, but there are limitations imposed by the platforms.
The hard part is that the palette is determined by the platform that
the display is running on, not the platform that Vim is running on,
and Vim can only reliably determine the latter, so some settings are
determined heuristically. That's a minor problem and not one that
Vim can solve.
My color scheme file is structured like this:
" Set Background
" Set Defaults
" Common Monochromatic Terminal Settings
" Common Color Terminal Settings
if &t_Co == 8
" PuTTY Color Settings
endif
if exists("$COLORTERM") && $COLORTERM == "gnome-terminal"
" Color GNOME Terminal Settings
endif
" Common GUI Settings
if has("gui_gtk2")
" GTK 2 (GNOME) GUI Settings
endif
if has("gui_win32")
" Windows GUI Settings
endif
Too complicated? Fine, but don't complain that you can't get the
colors you want. For me, it just works and solves the problem of a
consistent color scheme everywhere.
> 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!
This is a feature/limitation of the graphics system, not of Vim.
Tony seems to be the resident expert on this, but here's what I have
in my .vimrc/_vimrc:
if has("gui_running")
if has("gui_gtk2")
set guifont=Monospace\ 12
elseif has("x11")
set guifont=*-lucidatypewriter-medium-r-normal-*-*-180-*-*-m-*-*
elseif has("gui_win32")
set guifont=Courier_New:h10:cANSI
endif
endif
> 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?)
Because Windows users expect[ed] Vim to read _vimrc and Unix users
expect[ed] Vim to read .vimrc. If both happen to be in a user's
$HOME directory, Vim reads the one that it thinks the user expects
it to read. That makes sense to me. If only one of those two
files--either one--is in a user's $HOME directory, Vim reads that
one.
This behavior is only a problem to a user has both .vimrc and _vimrc
in their $HOME directory, the contents of the two files are
different, and the user expects Vim to read the one whose name is
not the one normally found on that system.
> 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?!)....
Computer operating systems and environments are not consistent.
That's just the way it is. Vim gives you the means to adapt its
configuration to the environment, and more thoroughly than any other
program I know of.
I have Vim installed on Windows XP Professional, Windows XP Home,
Fedora 11, Fedora 14, Ubuntu 8.04 and Ubuntu 10.04, all sharing a
common set of configuration files originally written for HP-UX and
Solaris. My Vim instances all look and behave pretty much the same,
whether gvim or vim, on Windows or Linux. That it works so well is
a tribute to Bram and his insistence on consistency across platforms
and revisions.
Given all I've read from you, the naming of Vim's configuration
files is the very least of your problems, and it shouldn't be
affecting your ability to solve the others.
You've made your pitch for changing those names. It's now up to
Bram to decide whether the change would be a net benefit. In the
mean time, if the naming thing is really holding you up, Ben and I
have given you a solution. I'd suggest that you implement it and
move on to the next problem.
As for this being a universal problem screaming to be solved: I
don't recall hearing of anyone else having a real problem with this.
If you'd like help with your other problems, choose one, explain it
here, and I'm sure we can come up with some solutions, or explain to
you why it can't be solved.
Regards,
Gary
--
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