Re: set vb t_vb=
Mark Woodward wrote: I'll send you my vimrc privately as an example; no need to spam the list with it. spam away ;-) no, all of you voyeurs, I believe it is too long (and still too uninteresting) for the list. Best regards, Tony.
set vb t_vb=
Hi vimers, I have a problem since my latest update to vim7. My vimrc file contains, among other things, set vb t_vb=. Because I don't like any kind of beeps or other warnings. Now, after the update, it gives me a visual beep/warning although I have the same vimrc. If I issue at runtime: :set vb t_vb= it's all back to normal. No more visual effects! This seems to me like a possible bug. Here's some info regarding my system: $ dmesg OpenBSD 4.0-beta (GENERIC) #1064: Tue Aug 15 15:37:34 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz (GenuineIntel 686-class) 2.40 GHz $ vim --version VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 12 2006 11:22:09) Included patches: 1-4, 6-26, 29-31, 33-42 Compiled by [EMAIL PROTECTED] Normal version with GTK2 GUI. Features included (+) or not (-): -arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv -cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript +printer -profile -python +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /usr/local/share/vim Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -O2 -pipe -I/usr/X11R6/include Linking: cc -L/usr/local/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/local/lib -o vim -L/usr/local/lib -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lfontconfig -lfreetype -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lXt -lcurses -lintl
Re: set vb t_vb=
On Sunday 27 August 2006 17:44, A.J.Mechelynck wrote:
Paul Irofti wrote:
Hi vimers,
I have a problem since my latest update to vim7. My vimrc file
contains, among other things, set vb t_vb=. Because I don't like
any kind of beeps or other warnings.
Now, after the update, it gives me a visual beep/warning although I
have
the same vimrc. If I issue at runtime:
:set vb t_vb=
it's all back to normal. No more visual effects!
By doing
:verbose set vb? t_vb?
you'll be able to see which script (if any) last set these options.
(I wonder what it may be).
It was, as I suspected, vimrc.
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.
Or if you don't want to bother with a gvimrc just for that, use the
following in your vimrc:
set vb t_vb=
if has('+autocmd') exists('##GUIEnter')
au GUIEnter * set t_vb=
endif
Best regards,
Tony.
Thanks for clearing things up a bit.
Paul.
Re: set vb t_vb=
On Sunday 27 August 2006 19:01, Paul Irofti wrote:
On Sunday 27 August 2006 17:44, A.J.Mechelynck wrote:
Paul Irofti wrote:
Hi vimers,
I have a problem since my latest update to vim7. My vimrc file
contains, among other things, set vb t_vb=. Because I don't like
any kind of beeps or other warnings.
Now, after the update, it gives me a visual beep/warning although
I have
the same vimrc. If I issue at runtime:
:set vb t_vb=
it's all back to normal. No more visual effects!
By doing
:verbose set vb? t_vb?
you'll be able to see which script (if any) last set these options.
(I wonder what it may be).
It was, as I suspected, vimrc.
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.
Or if you don't want to bother with a gvimrc just for that, use the
following in your vimrc:
set vb t_vb=
if has('+autocmd') exists('##GUIEnter')
au GUIEnter * set t_vb=
endif
And on another note, which didn't concern ports@, this exemple has no
effect apparently.
It would be pretty cool if I could keep all my gui and non-gui stuff in
one single file with something similar to what you described here.
Can you please point me to some related :he pages?
Best regards,
Tony.
Thanks for clearing things up a bit.
Paul.
Re: set vb t_vb=
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.
Re: set vb t_vb=
Paul Irofti wrote: [...] It would be pretty cool if I could keep all my gui and non-gui stuff in one single file with something similar to what you described here. Can you please point me to some related :he pages? [...] :help startup :help has() :help feature-list and in particular: gui_running :help exists() I'll send you my vimrc privately as an example; no need to spam the list with it. Best regards, Tony.
Re: set vb t_vb=
In article [EMAIL PROTECTED], Paul Irofti [EMAIL PROTECTED] wrote: On Sunday 27 August 2006 19:01, Paul Irofti wrote: On Sunday 27 August 2006 17:44, A.J.Mechelynck wrote: Paul Irofti wrote: Hi vimers, snip It would be pretty cool if I could keep all my gui and non-gui stuff in one single file with something similar to what you described here. I use: if has(gui_running) stuff endif I have not encountered any problems with that. I keep all my stuff in one vimrc file myself. I would be curious to see Tony's vimrc as well. I know he is a *master* Vimmer and probably has some gnarly stuff in there. :Robert
Re: set vb t_vb=
I'll send you my vimrc privately as an example; no need to spam the list with it. spam away ;-) -- Mark
Re: set vb t_vb=
I'll send you my vimrc privately as an example; no need to spam the list with it. spam away ;-) -- Mark I'm curious too, i know i'll learn a lot from it. regards, harvey
