separate gvim and vim in a single .vimrc [no .gvimrc]

[Harry Putnam]

Having trouble trying to use a single init (.vimrc) file for both vim
and gvim. I'd actually prefer just forget about gvim but some plugins
seem to need it... at least one that I want to learn to use. (xpt).

I pulled up lots of balderdash on google, and the 1 that actuall gave
a code example of how to do it... does not work here.

Found at: http://bugs.archlinux.org/task/10303

; Only apply this in gvim
if has("gui-running")
set whatever
endif

; Only apply this in non-gui vim
if !has("gui-running)
set whatever
endif

One place I see a problem is if I set one of the color schemes
available in gvim Edit/color scheme by typing

colors peachpuff

At the bottom of .vimrc

It has the desired effect in that gvim now opens with the peachpuff
color scheme, but it wrecks my syntax colors in vim. Appears to
revert them to default or something.... at least the appearance is
quite different than normal. (withouht `color peachpuff' in .vimrc)

So attempting to use the code found on google:

" Only apply this in gvim
if has("gui-running")
colors peachpuff
endif

That fixes it for vim, but now gvim fails to use the peachpuff color
scheme.

Is there some clear cut way to separate which editor load what from
.vimrc?

[Robert H]

I am not sure what you are describing. I have

colors whatever set pretty high in my .vimrc and lower down I have
my gui block:

if has("gui_running")
set guioptions+=acegtm
set guioptions-=T
set guifont=Menlo:12
set lines=50
set columns=100
set mouse=a
autocmd GUIEnter * set vb t_vb=
colorscheme desert
endif

I get the colorscheme I want in both.

Bob

I get the

[Jason Axelson]

On Sun, Sep 27, 2009 at 10:31 AM, Harry Putnam <rea...@newsguy.com> wrote:
> " Only apply this in gvim
>  if has("gui-running")
>    colors peachpuff
>  endif

I think it's just a simple typo. It should be gui_running with an
underscore rather than gui-running with a hyphen.

Jason

[Harry Putnam]

Robert H <sig...@gmail.com> writes:

[...]

> I am not sure what you are describing. I have

[...]

Turned out Jason say the problem

Jason Axelson <boston...@gmail.com> writes:

[...]

> I think it's just a simple typo. It should be gui_running with an
> underscore rather than gui-running with a hyphen.

Thanks Jason... you've got a sharp eye.

[Harry Putnam]

Harry Putnam <rea...@newsguy.com> writes:

Typo alert

> Turned out Jason say the problem

^ saw

[pansz]

Robert H 写道:

> if has("gui_running")
> set guioptions+=acegtm
> set guioptions-=T
> set guifont=Menlo:12
> set lines=50
> set columns=100
> set mouse=a
> autocmd GUIEnter * set vb t_vb=
> colorscheme desert
> endif

To be bug-free you must use the autocmd GUI Enter to do all .gvimrc
related stuffs.

reason:
1. you can switch from console vim to gvim with the command :gui
2. some options and settings are reset when starting the gui.

in this case:
a. .vimrc are source *without* "gui_running" defined
b. some of the options are reset
c. GUIEnter event and .gvimrc are sourced

so you should not rely on "gui_running" to do gui-related stuffs.

[Tim Chase]

> 1. you can switch from console vim to gvim with the command :gui

Well! I've been using vim for about 10 years and haven't
stumbled across this one before. Sweet! Thanks for sharing!

-tim
(please excuse the wanton excess of exclamation points :)

[Harry Putnam]

pansz <pans...@routon.com> writes:

>
> To be bug-free you must use the autocmd GUI Enter to do all .gvimrc
> related stuffs.

What does that mean... in terms of what goes in .vimrc?

[Harry Putnam]

pansz <pans...@routon.com> writes:

> reason:
> 1. you can switch from console vim to gvim with the command :gui
> 2. some options and settings are reset when starting the gui.
>
> in this case:
> a. .vimrc are source *without* "gui_running" defined
> b. some of the options are reset
> c. GUIEnter event and .gvimrc are sourced

Do your saying it can't be done from a single .vimrc file?

With the `gui_running' thing in .vimrc... if I call :gui, gvim starts but
doesn't get the settings under gui_running.

So how can I have gvim run with the settings in place, but not bother
my vim settings, and not have to maintain another init file?

[pansz]

Harry Putnam 写道:

> Do your saying it can't be done from a single .vimrc file?

No, I'm saying you should not rely on has("gui_running").

>
> So how can I have gvim run with the settings in place, but not bother
> my vim settings, and not have to maintain another init file?

If you want to omit the .gvimrc, you should put everything you want in
your .gvimrc in the GUIEnter autocommand. and of course, you can put the
autocommand in your .vimrc, something like:

autocmd GUIEnter *
\ foobar1
\ foobar2
\ foobar3

[Ben Fritz]

On Sep 27, 10:10 pm, pansz <panshi...@routon.com> wrote:
> > So how can I have gvim run with the settings in place, but not bother
> > my vim settings, and not have to maintain another init file?
>
> If you want to omit the .gvimrc, you should put everything you want in
> your .gvimrc in the GUIEnter autocommand.

Or, you could refrain from using the :gui command and launch gvim when
you want gvim, and vim when you don't.

[Robert H]

I have probably never had an issue because I always launch the one I
want. I don't move from one to the other.

Bob

[Matt Wozniski]

Even so, some settings (like t_vb) must be set from either a .gvimrc
or from a GuiEnter autocmd. If they're set from .vimrc, they are
silently reset to their original value when gvim is started. So the
only right ways to do it, for all options, is either with a .gvimrc
file or with GuiEnter autocmds.

~Matt

[Robert H]

There must be a lot of wrong wayers out there. Every example .vimrc that
I have seen that has a gui section does not prepend GuiEnter onto the
settings.

Since this is all I am doing:

if has("gui_running")
set guioptions+=acegtm
set guioptions-=T
set guifont=Menlo:12
set lines=50
set columns=100
set mouse=a
autocmd GUIEnter * set vb t_vb=
colorscheme desert
endif

Do I really need more than that GUIEnter? If I do then how does that
change the above? Do I have multiple GUIEnter * set ... commands?

Bob

[pansz]

Robert H 写道:

> if has("gui_running")
> set guioptions+=acegtm
> set guioptions-=T
> set guifont=Menlo:12
> set lines=50
> set columns=100
> set mouse=a
> autocmd GUIEnter * set vb t_vb=
> colorscheme desert
> endif
>
> Do I really need more than that GUIEnter? If I do then how does that
> change the above? Do I have multiple GUIEnter * set ... commands?

For your specific need, this is enough. If we're talking about a generic
solution, multi-line GUIEnter autocmd is the way.

Personally, I'd recommend a separate ~/.gvimrc. Since in most cases I
use the console vim, remove the gui stuffs in ~/.vimrc speeds up vim a
little. [at least it checks the :if has("gui_running") and search for
:endif, which takes time]

But your mind may vary.

[Matt Wozniski]

On Tue, Sep 29, 2009 at 5:51 PM, Robert H wrote:
>
> On 9/28/09 6:06 PM, Matt Wozniski wrote:
>>
>> On Mon, Sep 28, 2009 at 5:16 PM, Robert H wrote:
>>>
>>> On 9/27/09 9:04 PM, pansz wrote:
>>>>
>>>> To be bug-free you must use the autocmd GUI Enter to do all .gvimrc
>>>> related stuffs.
>>>

>>> I have probably never had an issue because I always launch the one I
>>> want. I don't move from one to the other.
>>
>> Even so, some settings (like t_vb) must be set from either a .gvimrc
>> or from a GuiEnter autocmd.  If they're set from .vimrc, they are
>> silently reset to their original value when gvim is started.  So the
>> only right ways to do it, for all options, is either with a .gvimrc
>> file or with GuiEnter autocmds.
>
> There must be a lot of wrong wayers out there. Every example .vimrc that
> I have seen that has a gui section does not prepend GuiEnter onto the
> settings.

Not necessarily "wrong way" - just not generic enough to work for all options.

> Since this is all I am doing:
>
> if has("gui_running")
>      set guioptions+=acegtm
>      set guioptions-=T
>      set guifont=Menlo:12
>      set lines=50
>      set columns=100
>      set mouse=a
>      autocmd GUIEnter * set vb t_vb=
>      colorscheme desert
> endif

You set 8 options here, two of which are already done on GuiEnter
instead of when the .vimrc file is first read. So, somewhere along
the way, you must have found out about this problem, and the GuiEnter
work around.

You chose not to use GuiEnter for the *other* 6 settings, because they
worked. But, short of trial-and-error or very in-depth knowledge,
this isn't a great solution. Using GuiEnter for everything is easier
and less error-prone.

> Do I really need more than that GUIEnter? If I do then how does that
> change the above? Do I have multiple GUIEnter * set ... commands?

In your case, no, you've already special-cased the 2 that need it. In
general, though, it's safest to set all GUI options inside one or more
GuiEnter autocmds. Which means, really, that it's easiest to just use
a .gvimrc - you can think of a .gvimrc as just a file that gets
:sourced from a GuiEnter autocmd; it's basically equivalent.

~Matt

[Robert H]

Except in that case I have to maintain two files and not one. Actually
that one GUIEnter probably comes from another vimrc that I was looking at.

[Tony Mechelynck]

Actually, you don't have to put _everything_ GUI-related in autocommands:

- On Windows, a single binary is either a console utility or a GUI, but
not both, so if you're Windows-only has("gui_running") is enough [and
equivalent to has("gui")]. Or even if you use a single vimrc on both
Windows and Linux, has("hui_running") is criterion enough to know when
to set which Windows-specific settings: for instance, the 'guicursor'
setting specific to the Dos/Windows console.
- Even on Unix, if you know in advance that you won't be using the :gui
command, has('gui_running') is good enough for you.
- Many GUI-related settings have no effect in Console Vim, except that
it remembers them for when (and if) the GUI will be started. A few of
these are
'guifont'
'guioptions'
'guicursor' (except on Dos/Windows, see above)
There are others. You can set these in your vimrc without bracketing
them in has('gui_running'); or (if you sometimes run non-GUI-enabled
versions) by bracketing them in just has("gui") to prevent an error on
versions which don't recognise the option.

There are a few settings, however, which are always reset at GUI
startup, and these require either a gvimrc or a GUIEnter autocommand,
even (I think) on Windows. One of these is 't_vb', as explained under
the help for 'visualbell'. For instance, if you want both a visual and
an audible bell, here's how to do it in all versions of Vim on most
kinds of display (using the ASCII control character BEL):

set errorbells visualbell
if !has('gui_running') " console Vim setting
let &t_vb = "\x07" . &t_vb " also ring the bell
endif
if has('autocmd') && has('gui')
" must set it again for the GUI
au GUIEnter * let &t_vb = "\<C-G>\e|50f"
" where 50 = flash time in milliseconds (default 20)
endif

Similarly, (unless you'll never be using the :gui command) if you want
to use, let's say, a _different_ colorscheme in Console Vim and in gvim,
or _different_ 'lines' and 'columns' settings, etc., you have to set the
GUI setting in a gvimrc or at the GUIEnter event. (There are
colorschemes which work in both gvim and Console Vim, and not
necessarily with the same colours; or if your console has 88 colours or
more, you can avail yourself of the CSApprox plugin to make a
gui-enabled Console vim use "the best approximation" to what it would
use as a GUI).

[pansz]

Tony Mechelynck 写道:

> set errorbells visualbell
> if !has('gui_running') " console Vim setting
> let &t_vb = "\x07" . &t_vb " also ring the bell
> endif
> if has('autocmd') && has('gui')
> " must set it again for the GUI
> au GUIEnter * let &t_vb = "\<C-G>\e|50f"
> " where 50 = flash time in milliseconds (default 20)
> endif

simply put gui-related stuffs in a function and put that function inside
GUIEnter works great.

I don't think it is a good way to separate your settings in
has('gui_running') and GUIEnter. People are forced to remeber those
things while otherwise unnecessary.

If you put has('gui_running') and GUIEnter all over your .vimrc your
.vimrc will increasingly become unreadable and difficult to maintain,
while a single function triggered by GUIEnter is much easier to
maintain. and by removing some unnecessary ":if has()"s .vimrc executes
better.

Think, you merge .gvimrc and .vimrc in order to retain elegance, but you
leave some unpleasant code inside your .vimrc, why not try to make the
code read better and runs better?