Describe the bug
On my machine, having set guioptions-=T in my .vimrc causes start up to hang for 25 seconds.
To Reproduce
if has("gui_running")
set guifont=Fira\ Code\ Retina\ 10
set guioptions-=M
set guioptions-=m
set guioptions-=r
set guioptions-=T
nnoremap <leader>t :if &go=~#'T'<Bar>set go-=T<Bar>else<Bar>set go+=T<Bar>endif<CR>
endif
This causes the start up to hang for 25 seconds. Commenting out set guioptions-=T results in a near instant start up.
Expected behavior
Disabling the toolbar should not result in such a huge start up delay.
Environment (please complete the following information):
:version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep 05 2019 11:15:15)
Included patches: 1-875, 878, 884, 948, 1046, 1365-1368, 1382, 1401
Modified by team...@tracker.debian.org
Compiled by team...@tracker.debian.org
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +cmdline_compl +emacs_tags +insert_expand +modify_fname +netbeans_intg +ruby +terminfo +vreplace
+arabic +cmdline_hist +eval +job +mouse +num64 +scrollbind +termresponse +wildignore
+autocmd +cmdline_info +ex_extra +jumplist +mouseshape +packages +signs +textobjects +wildmenu
+autochdir +comments +extra_search +keymap +mouse_dec +path_extra +smartindent +textprop +windows
-autoservername +conceal +farsi +lambda +mouse_gpm +perl +startuptime +timers +writebackup
+balloon_eval +cryptv +file_in_path +langmap -mouse_jsbterm +persistent_undo +statusline +title +X11
+balloon_eval_term +cscope +find_in_path +libcall +mouse_netterm +postscript -sun_workshop +toolbar -xfontset
+browse +cursorbind +float +linebreak +mouse_sgr +printer +syntax +user_commands +xim
++builtin_terms +cursorshape +folding +lispindent -mouse_sysmouse +profile +tag_binary +vartabs +xpm
+byte_offset +dialog_con_gui -footer +listcmds +mouse_urxvt -python +tag_old_static +vertsplit +xsmp_interact
+channel +diff +fork() +localmap +mouse_xterm +python3 -tag_any_white +virtualedit +xterm_clipboard
+cindent +digraphs +gettext +lua +multi_byte +quickfix +tcl +visual -xterm_save
+clientserver +dnd -hangul_input +menu +multi_lang +reltime +termguicolors +visualextra
+clipboard -ebcdic +iconv +mksession -mzscheme +rightleft +terminal +viminfo
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/cai
ro -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/
pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid -I/usr/include/
freetype2 -I/usr/include/libpng16 -Wdate-time -g -O2 -fdebug-prefix-map=/build/vim-msfmDW/vim-8.1.0875=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_F
ORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-need
ed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lI
CE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/usr/lib -llua5.2 -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/lib/x86_64-li
nux-gnu/perl/5.28/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm -L/usr/lib/x86_64-linux-gnu -lt
cl8.6 -ldl -lz -lpthread -lm -lruby-2.5 -lpthread -lgmp -ldl -lcrypt -lm
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
I found a PPA which has fixed the problem:
:version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Nov 12 2019 12:02:28)
Included patches: 1-2292
Modified by jonathon....@york.ac.uk
Compiled by jonathon....@york.ac.uk
Huge version with GTK3 GUI. Features included (+) or not (-):
The PPA is here: https://launchpad.net/~jonathonf/+archive/ubuntu/vim
Closed #5246.
Exactly the same problem. Thanks!
Same problem on ubuntu daily 20.04, with both vim versions 8.1 and 8.2, @darkermatter solution didn't work for me
does it matter, whether you use gtk2 or gtk3 build? Does
:aucmd VimEnter * :set guioptions-=T
make a difference?
In my case, I have solved the mystery. It's not a problem of gvim. For some reason orca is running in the background. Once I killed the process, gvim goes back to normal.
I found a PPA which has fixed the problem:
:version VIM - Vi IMproved 8.1 (2018 May 18, compiled Nov 12 2019 12:02:28) Included patches: 1-2292 Modified by jonathon....@york.ac.uk
Compiled by jonathon....@york.ac.uk Huge version with GTK3 GUI. Features included (+) or not (-):
The PPA is here: https://launchpad.net/~jonathonf/+archive/ubuntu/vim
Anybody know how this PPA get this issue fixed? A self-compiled Vim 8.2.3868 (both GTK3 and GTK2) on Ubuntu 20.04 encounters this issue when guioptions-=T is set.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
Just ran into this. @chrisbra's suggestion to use an autocmd worked. Not sure why, I've used this exact vim config and install config on several other systems (including a few on the exact same OS version), where it's fine. If the issues stems from hardware, the only real difference is that this machine has an AMD CPU, instead of Intel (and a newer graphics card, but I don't really think that's relevant; it's still the same brand as the other computers, where there's some pretty substantial generational leaps already)
In the meanwhile, an autocmd is a nice hack to get around this, whatever the cause is. If this is still a concern worth fixing, I'd be happy to help with debugging if necessary. I'm able to reproduce it consistently, even with a minimal vimrc consisting purely of set guioptions-=T. --startuptime, for reference (though against my current, full .vimrc):
071.979 000.147: loading after plugins
071.984 000.005: inits 3
081.891 000.792 000.792: sourcing $VIMRUNTIME/menu.vim
25166.967 25094.191: starting GUI
25167.080 000.113: reading viminfo
25167.489 000.409: GUI delay
Can't find a "starting GUI" string in menu.vim, so I assume it's from some C code. That's outside the scope of where I can easily search at the moment, though.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()