[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-ports
Subject:    Re: set vb t_vb=
From:       "A.J.Mechelynck" <antoine.mechelynck () skynet ! be>
Date:       2006-08-27 18:35:24
Message-ID: 44F1E5EC.4060606 () skynet ! be
[Download RAW message or body]

Paul Irofti wrote:
> On Sunday 27 August 2006 17:44, A.J.Mechelynck wrote:
[...]
>> Note that if you use gvim, t_vb is reset at its gvim default when
>> starting the GUI (after having sourced the vimrc). You may want to
>> set it to empty in both your vimrc (to avoid a visual bell in Console
>> Vim) and your gvimrc (for the GUI).
> 
> That was the problem. I thought vimrc was read first and afterwards, if 
> gvim was lunched, the gvimrc. I kept only gui specific stuff in gvimrc 
> such as:
> 
> set guioptions-=m
> set guioptions-=T
> set guioptions-=r
> set guifont=Terminus\ 12
> set lines=50
> set columns=100
> 
> Is this normal behaviour? I remember reading that vimrc had precedence 
> and don't remember seeing any notes about gvim overwritting some of the 
> stuff there.
[...]

What happens is (skipping a few details -- see ":help startup" for the 
full scenario):

1. set 'term' for the console; set v:lang, v:ctype, etc.
2. source vimrc
3. source global plugins (equivalent to ":runtime! plugin/*.vim")
4. (only if GUI) start GUI, set term=builtin_gui
5. (only if GUI) source gvimrc
6. (only if GUI) trigger GUIEnter
7. trigger VimEnter
8. wait for the user to do something at the keyboard (and/or mouse).

However, as noted under ":help visualbell", at step 4 all t_xx entries 
are set to their GUI defaults, so any "set t_vb=" statement in the vimrc 
is overridden here. Very few termcap entries can be altered once the GUI 
is started.

Note that since the gvimrc is read after the vimrc, it can override 
anything set by the vimrc. OTOH, the function has("gui_running") returns 
TRUE not only after starting the GUI, but even while sourcing the vimrc 
if the GUI is "going to be started". This allows the vimrc to contain 
GUI-specific, and, more important, console-specific blocks of code. 
(That's why I don't have a gvimrc even though I use gvim much more often 
than console Vim.)

Also, under Windows different executables are required for gvim and 
console Vim; in that case steps 1-3 above are run with no output device 
when in gvim; in that case if a message is issued at that stage 
(including the output of --help or --version), it will be displayed in a 
popup.


Best regards,
Tony.

[prev in list] [next in list] [prev in thread] [next in thread]