Since I upgraded to gvim-7.0-r2, I can no longer run programs in the background. For example, I used to be able to do, !kdvi& to open kdvi, and get back control of gvim. This now only works if gvim is started from a terminal. A bunch of features from vim-latex won't work because of this. I can run programs in the forground (i.e. !kdvi).
I can see this too, it doesn't actually matter whether it's started from a terminal, but whether it's started with the --nofork option (which was necessary to add to the .desktop file) That is, :!konqueror& does work when 'gvim' is run from a terminal, but does not work when
I can see this too, it doesn't actually matter whether it's started from a terminal, but whether it's started with the --nofork option (which was necessary to add to the .desktop file) That is, :!konqueror& does work when 'gvim' is run from a terminal, but does not work when ´gvim -f' or 'gvim -f&' is run from a terminal (even though gvim without options is supposed to act like gvim -f&)
A workaround for the moment is to add: set guioptions="aegimrLtTf" to your vimrc. This forces it to never fork.
I'm sorry, what you really want is: set guioptions=aegimrLtTf (those quotes weren't right).
That doesn't solve the problem for me.
I can't seem to reproduce your problem when I force gvim to be invoked with the nofork option (either by running it with the -f option recommended by Harald, or with the guioptions setting recommended by me). Could you please attach your ~/.vimrc and ~/.gvimrc (if either exists)? What specific version of app-editors/gvim are you using? What USE flags was it compiled with? Also, how are you invoking gvim if not by the console? Are you using an icon in your desktop environment's menu? The vim.desktop file installed by gvim defaults to invoking gvim with the -f option, which, again, should prevent the problem you are seeing. If your desktop environment / window manager doesn't use the fdo-style menu items, be sure that you edit your menu to execute gvim -f instead of just gvim.
> What specific version of app-editors/gvim are you using? What USE flags was it > compiled with? I can see the problem with [ebuild R ] app-editors/gvim-7.0.109 USE="acl gtk nls perl (-aqua) -bash-completion -cscope -gnome -gpm -motif -mzscheme -netbeans -nextaw -python -ruby" 0 kB without any .vimrc. > The vim.desktop file installed by gvim > defaults to invoking gvim with the -f option, which, again, should prevent the > problem you are seeing. The other way around, actually. Other problems occur if the -f option is not used, but this problem exists only if it is.
Weird... I can't seem to reproduce this. Try these commands from a terminal window: # gvim -u NONE -U NONE -c ':!xterm&' # gvim -u NONE -U NONE -c ':!xterm&' -f For me, both these start gvim, which then spawns an xterm. I can interact fine with both the xterm and with gvim. In fact, I can close one or the other, and the remaining window still works fine. What do those two commands do for you?
(In reply to comment #7) > Weird... I can't seem to reproduce this. Try these commands from a terminal > window: > > # gvim -u NONE -U NONE -c ':!xterm&' > # gvim -u NONE -U NONE -c ':!xterm&' -f > > For me, both these start gvim, which then spawns an xterm. I can interact fine > with both the xterm and with gvim. In fact, I can close one or the other, and > the remaining window still works fine. What do those two commands do for you? They work the exact same way for me. And I see if I get rid of not only my ~/.vimrc but also /etc/vim, gvim behaves properly. If I then recreate ~/.vimrc, but as a zero-length file, gvim ends up broken again.
Sorry, Brian, but I think I'm out of suggestions. This is a bug with the source code of the package, so I'd suggest you send a message to the vim-dev mailing list and folks will be able to help you better there. When Bram releases an official patch, I'll include it in Gentoo. See http://www.vim.org/maillist.php for more info on posting to vim-dev.
