Mail Archives: cygwin/2009/11/22/23:30:24
On 2009-11-21, Linda Walsh wrote:
> Gary Johnson wrote:
> >You could do that, or you could add the full path to the vim
> >directory to your PATH.
> ---
> This is a very circuitous story -- with different effects
> developing over the years. Things might be different under
> cygwin 1.7, but I went through various kludges to get vim to
> work everywhere I wanted it to.
>
> I had to search around to find why I did what I did.
> If I'm at the shell prompt, and type 'vi', I want the
> Cygwin 'vim' shell version to come up.
Since Cygwin puts its bin directories first in its PATH, this should
happen without any work on your part.
> If I type 'gvim', I want the Windows version to come
> up. If I want to use the cygwin graphical version, I have to
> use an alternate name and -g, but I don't use it often, so not
> a big deal.
If you've installed Cygwin's gvim, then it will in your PATH ahead
of the Windows gvim. You can fix that by creating a shell script
named gvim, putting it in /usr/local/bin, and having it execute the
Windows gvim.
> But the problem with using the Gvim in /prog/vim
> directly is that it doesn't auto-daemonize when invoked from
> bash. So I wrote a program to call and fork it in
> background.
You could do that with the /usr/local/bin/gvim script, too:
/cygdrive/c/prog/vim/gvim.exe "$@" &
> But unfortunately, when vim would look for
> it's runtime, it looked at the path of the invoking
> program which for compatibility as a replacement for
> noteplad, had to sit in \windows\system32. Some programs only
> looked in there for the system text editor and didn't look
> at the path.
Maybe that's the problem: you had vim use the path of the invoking
program to select its runtime files instead of some more reliable
means.
At one time, I had my Windows vim and Cygwin vim sharing the same
runtime files. To do that, I put something like this at the very
top of my .vimrc:
if has("win32unix")
" Edit &rtp to use common runtime files.
elseif has("win32")
" Edit &rtp to use common runtime files.
endif
It worked fine. I've since adopted a method I like better so I
don't use that any more, but not because it didn't work.
> As a result, Vim didn't know where it's runtime was. So I
> had to set it in the env vars. to C:/prog/vim. (I keep my vim in
> /prog/vim, not an every changing /prog/vim/vimX, because the registry
> needs fixed paths.
I just set any registry entries to point to the latest version of
vim and change them when vim's revision number changes. Vim's
version doesn't change that often and I don't have the path to gvim
in so many places that it's a big problem. I agree that it would be
nice not have to do that at all, though.
> So my various 'hacks' accumulated over the years do compensate
> for various Windows programs that didn't use the path and/or that
> required a fixed path for the editor.
>
>
> >There is something wrong there. That shouldn't be necessary.
> >
> >I'm not sure which config files you mean. Windows gvim uses
> >C:\Program Files\Vim\vim7 for its standard runtime files whereas
> >Cygwin vim uses /usr/share/vim/vim72.
> ---
> Like I said -- I moved them up a level, and 'program files'
> dir is named 'prog', so it's in C:/Prog/vim. (Win Vim accepts forward
> slash as a path separator just as cygwin vim does).
>
> If I used VIMRUNTIME=C:\Prog\Vim, then cygwin vim sees
> that as C:ProgVim. Thus VIMRUNTIME=C:/Prog/Vim.
I wouldn't expect "C:/Prog/Vim" to work with Cygwin vim, especially
with Cygwin 1.7, at least from the discussions I've been reading in
this list. Whenever I set an environment variable like that, I
check the OS being used and format the path accordingly.
> Cygwin Vim doesn't handle CRLF, But WinVim understands
> CRLF OR LF. So WinVim get's it's RUNTIME converted to unix format
> so that run time works with Cygwin's vim as well as Win Vim.
Yep. As I said, I don't share the system runtime files, but I do
share my ~/.vim or ~/vimfiles files and those I have to make sure
are in LF format.
> >There is no reason to share
> >those files between Windows and Cygwin versions of vim.
> ----
> At one point I was using customized versions of the runtime
> before I figured out how to put them in my local dir. But keeping
> 1 run time means I can update 1 runtime's files and both versions
> will get updated. (spell files and such get shared as well).
I did that for a while, too. The main problem I had with it was
that it meant updating both Cygwin and Windows vim installations at
the same time with vim versions that could both use the latest
runtime files. Since I usually update vim when it's convenient and
in the cracks in my schedule, that didn't work at all well for me.
It also made it difficult to go back to an earlier version of vim if
the latest version displayed a bug.
> >I think if you fixed your vim configuration to something not quite
> >so exotic, you might not have those problems. Granted I'm using XP,
> >but I use both Cygwin 1.5 and 1.7 on different machines and I never
> >see problems with vim and gvim that depend on where or how they're
> >started.
> ---
> And you can start gvim from bash and have it background
> like it does in 'cmd.exe'?
If it's important that it be in the background and I think about
what I'm doing, I just start it as "gvim <arguments> &". If it
became a sufficient annoyance, I'd just use a /usr/local/bin/gvim
script as I described above.
> And you can run it from the 'run command'?
I never do that, but I just tested it and, yes, I can.
> And it comes up with you edit .txt files or .reg, or any
> plain text file?
Yes, because I have the Windows file associations set to use gvim
for .txt, .vim and certain other extensions.
> My registry's been pretty well honed for comfort, not
> standardization. My home directory is named /home, not 'documents and
> settings'. My cygwin home shares my winhome. I'm trying to work
> it so my linux home dir is also my profile dir -- which means my
> cygwin /home dir would also be my linux server /home dir.
I'm not sure that would be a good idea. For one thing, in my
experience, accessing any network file system from Windows is
significantly slower than accessing a local file system. For
another, I don't think you'd be able to use any symlinks to map
~/.vim to ~/vimfiles or vice versa, since only Linux symlinks would
be supported on a Linux file system and Windows would not be able to
follow those. At least it hasn't worked when I've tried it.
> Anyway, hope this explains my vim setup (Recap:
>
> Cygwin Vim shares Win-Vim's runtime dir because
> I have VIMRUNTIME set. That needs to be set, because
> vim doesn't know how it was called. Why? Because...
> it was called from a wrapper. Why? Because...
> gvim won't daemonize under cygwin from it's shell.
>
> Simple chain of logic...:-)
Thanks for taking the time to explain that. I still don't
understand the "vim doesn't know how it was called" part, though, or
why it matters. I think the "has('win32unix') and/or "has('win32')"
calls in your .vimrc would solve that issue.
Regards,
Gary
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -