Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a problem with gvim where the screen redraw partially fails. It's hard to explain but when I open a text file and page down or up the entire text file is not redraw properly. I have to move the cursor first before it redraws. I've got a screencapture here of it since it demonstrates the problem: http://www.box.net/shared/l4m1vrffl0dhigi80huz

It seems as if the issue is limited to gvim because every other application I run is fine and redraws properly. It's quite easy for me to reproduce in gvim. The console vim is fine. It makes me think the issue is limited to gvim.

OS is Arch linux 3.0 running the nvidia drivers running Gnome3 (no compiz).

Output from uname

Linux cyclops 3.0-ARCH #1 SMP PREEMPT Tue Aug 30 07:32:23 UTC 2011 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux

lsmod

lsmod | grep nvidia
nvidia              10225284  40 
agpgart                22096  1 nvidia
i2c_core               16625  2 nvidia,i2c_nforce2

gvim --version

gvim --version VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep 30 2011 05:51:10) Included patches: 1-322 Compiled by ArchLinux Big 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 +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm

-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg +path_extra +perl +persistent_undo +postscript +printer -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +startuptime +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: "/etc/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "/etc/gvimrc" user gvimrc file: "$HOME/.gvimrc" 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/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/local/include -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=1 Linking: gcc -L. -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -L/usr/local/lib -Wl,--as-needed -o vim -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -fstack-protector -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -lruby -lpthread -lrt -ldl -lcrypt -lm -L/usr/lib

share|improve this question
2  
I have this same exact problem in Ubuntu 12.10, under Gnome 3. You are the only other person on the internet that I've found to have it. Any luck since posting this? –  jakar Mar 6 '13 at 3:17
    
@jakar No I never found a way to fix this. I'm now running fc17 with nvidia drivers and don't see the problem anymore, but I'm not using Gnome 3 in it's fancy mode. –  sashang Mar 6 '13 at 5:38
    
Yeah, I think it has more to do with gnome/gtk/xorg/drivers than with gvim itself. I don't have any problems in fc17 either (though on a different machine), even running matching versions of gvim, built from source. Oh well, I'll live with it for now. At the very least, thanks for the only good description and video of this that I've seen. –  jakar Mar 6 '13 at 21:35
    
I also have this problem. I'd be really interested in a solution. –  Matt Fichman Mar 16 '14 at 12:12
    
This sounds a lot like issue 91 and my current guess is, that this is a gtk library issue. –  Christian Brabandt Mar 24 at 17:56

2 Answers 2

It would help to provide info on your OS, video card, etc. Looks like GNOME3 on ...?

I had a problem like this when running GVIM and other apps with Compiz as my Window Manager with an NVIDIA video card, and fixed it by going to "Compiz Config Settings Manager" > Workarounds > check "Qt Window Fix".

No clue if this, or something else, will help in your case or not, especially if you're using Mutter instead of Compiz.

share|improve this answer

What kind of plugins do you have jacked into Vim beyond what came bundled out of the box?

There may be a chance one of your normally stable plugins went a little glitchy on you. Yes, GTK is revealing the problem, but it is likely not THE problem. Anything that creates popup-windows or temporarily creates a mini-buffer or something like that. Autocompletion, snippets, ... If its an extra plugin or feature, try turning it off and see if your issue goes away.

Although I did not see any such popups in your movie, the plugin may be creating its popup, realizing its not actually needed, clearing the popup, but then not redrawing the content that was originally underneath.

Doing a full screen scroll does not repaint the entire buffer. Cursor is obviously forcing the buffer to repaint neighbors.

Of course it could be a core GTK/GVim problem (I think that X or OpenGL have nothing to do with it), but it seems unlikely to me (although I don't commonly use Arch).

If you do find that its a plugin, you may want to force a version upgrade or downgrade (anything but the "broken" version).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.