gvim not showing buffers unless you `:redraw!`

[pmav99]

Archlinux x64

$ awesome --version
awesome v4.1-2-g4a21fc5b (Technologic)
 • Compiled against Lua 5.3.4 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.1

$ gvim --version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar  6 2017 14:11:23)
Included patches: 1-427
Compiled by Arch Linux
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_old_static
+arabic          +find_in_path    -mouse_sysmouse  -tag_any_white
+autocmd         +float           +mouse_urxvt     +tcl/dyn
+balloon_eval    +folding         +mouse_xterm     +termguicolors
+browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     +gettext         -mzscheme        +textobjects
+channel         -hangul_input    +netbeans_intg   +timers
+cindent         +iconv           +num64           +title
+clientserver    +insert_expand   +packages        +toolbar
+clipboard       +job             +path_extra      +user_commands
+cmdline_compl   +jumplist        +perl/dyn        +vertsplit
+cmdline_hist    +keymap          +persistent_undo +virtualedit
+cmdline_info    +lambda          +postscript      +visual
+comments        +langmap         +printer         +visualextra
+conceal         +libcall         +profile         +viminfo
+cryptv          +linebreak       +python/dyn      +vreplace
+cscope          +lispindent      +python3/dyn     +wildignore
+cursorbind      +listcmds        +quickfix        +wildmenu
+cursorshape     +localmap        +reltime         +windows
+dialog_con_gui  +lua/dyn         +rightleft       +writebackup
+diff            +menu            +ruby/dyn        +X11
+digraphs        +mksession       +scrollbind      -xfontset
+dnd             +modify_fname    +signs           +xim
-ebcdic          +mouse           +smartindent     -xpm
+emacs_tags      +mouseshape      +startuptime     +xsmp_interact
+eval            +mouse_dec       +statusline      +xterm_clipboard
+ex_extra        +mouse_gpm       -sun_workshop    -xterm_save
+extra_search    -mouse_jsbterm   +syntax          
+farsi           +mouse_netterm   +tag_binary      
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/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/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_FORTIFY_SOURCE=2  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -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 -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 -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/perl5/core_perl/CORE -lperl -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc   -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lieee -lm     

How to reproduce the issue:

This is not 100% reproducible. It happens most of the time but not always.

1. Open gvim on a tag with max layout
2. Create two (vertical) buffers (:vsp)
3. Move to a different awesome tag (e.g. on the browser)
4. Return to the tag where gvim is running

Actual result:

You see a grey image: http://i.imgur.com/b6jyEWI.png

Expected result:

We should be seing normal vim buffers.

Workaround

If we issue :redraw! the buffers are restored. But you need to do that each time you move to a different tag and it quickly becomes annoying.

Further info

This did not happen on 3.5.9 You can reliably reproduce it on 4.0.x On 4.1.x this still happens, but not as reliably

I am not the only one facing this (or a similar issue): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856920 According to the vim devs there has not been any recent changes on the vim-side. discussion: https://groups.google.com/forum/#!msg/vim_dev/gC2rOlgZx88/8Hn0fjfODQAJ

[psychon]

Try starting awesome with the --no-argb flag (this breaks transparency!). If the flag helps with this issue, then you are running into a video driver bug and the X server is the right thing to check.

If you don't mind compiling your own X server to test patches, you could try out the patches that are link to at https://bugs.freedesktop.org/show_bug.cgi?id=99220.

[pmav99]

@psychon I tried to start awesome with --no-argb but it didn't help. Any other suggestions?

I am using intel's open source drivers by the way:

$ pacman -Qs intel
local/intel-tbb 2017_20170226-1
    High level abstract threading library
local/intel-ucode 20161104-1
    Microcode update files for Intel CPUs
local/lib32-mesa 17.0.1-2
    an open-source implementation of the OpenGL specification (32-bit)
local/mesa 17.0.1-2
    an open-source implementation of the OpenGL specification
local/xf86-video-intel 1:2.99.917+767+g7e9e92c8-1 (xorg-drivers)
    X.org Intel i810/i830/i915/945G/G965+ video drivers

[psychon]

Any other suggestions?

This did not happen on 3.5.9

You could try a git bisect, but it's not completely easy. Newer versions of awesome can be tested easily with make && tests/run.sh /dev/null (this needs Xephyr, it gives you ~2 minutes to test things and then claims that the test /dev/null failed). However, older versions do not have this script in git.

So far I have no idea about this issue.

[sriedel]

I have the exact same situation as @pmav99, also arch 64bit with the intel X11 driver.

$ awesome -version
 awesome v4.0 (Harder, Better, Faster, Stronger)
  • Compiled against Lua 5.3.3 (running with Lua 5.3)
  • D-Bus support: ✔
  • execinfo support: ✔
  • RandR 1.5 support: ✔
  • LGI version: 0.9.1

Since working with gvim is 90% of my screen time, this issue is really painful for me. So if you need another guinea pig, I'm game :)

I'll try and make time for a git bisect this weekend, however I'm not sure how much time I'll actually have, so no promises.

[teranex]

I recently upgraded to Awesome 4.0 using the build from this ppa and I see the same issue, both on my Dell Latitude E6530 as well as on my Acer C720P (Chomebook running GalliumOS). When I start Gvim, the tabbar is not drawn. Also, when switching back to the tag with Gvim, the Gvim-window is entirely gray. The last issue can be fixed by pressing so Gvim redraws, but the tabs are still not drawn. I did found out however that setting 'size_hints_honor = true' for Gvim seems to fix the issue (I set size_hints_honor = false in the global rule).

[boris-petrov]

Same thing happens with me but when I use gVim over ssh -Y. Didn't happen before 4.0, now it is like so even in 4.1.

[psychon]

I'd still suggest a bisect. Doing so between 4.0 and 4.1 is also a lot easier than between 3.5.9 and 4.1, for example because tests/run.sh /dev/null works in all intermediate revisions.

[sriedel]

So I had a go at bisected a few weeks ago. Testing 7818fd3d I couldn't reproduce the problem. However I am not sure if I can actually nail down the conditions needed to trigger the issue. I've tried the size_hints_honor both with true and false (wasn't explicitly set before) and found that while the issue initially disappeared, after half an hour of switching windows and creating and removing vertical splits in gvim the issue was suddenly back.

So I don't feel proceeding with the bisect is a feasable approach until we have the conditions of the issue nailed down - or someone is brave enough to use the current git bisect step as their regular work environment and do a bisect every day (or whenever the issue is triggered).

A bit of a catch22 :/

[blueyed]

@pmav99

1. Open gvim on full screen.

From your screenshot it looks more like you are using it on a "max" layout?!

With that I could actually reproduce it now (but not the first time I've tried it).

For me it only happens on the laptop display, but not the external screen though..! I am using a Lenovo X250, with an 2560x1440 external display.

[pmav99]

Yes I am using the max layout

[blueyed]

It also happens with v4.0 for me though, too.

I stopped bisecting at v3.5.60-2144-g333cd649 (last bad), since it failed to build then:

/usr/bin/ld: CMakeFiles/awesome.dir/awesome.c.o: undefined reference to symbol 'XGetXCBConnection'
/usr/lib/libX11-xcb.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

[psychon]

/usr/bin/ld: CMakeFiles/awesome.dir/awesome.c.o: undefined reference to symbol 'XGetXCBConnection'

Remove the temporary CMake files (the whole .build* directory, but just build/CMakeCache.txt might be enough) to get CMake to re-run things and notice that it should now link in one more library. Fun...

[blueyed]

I've tried make distclean, but that was not cleaning the proper build directory apparently. I cannot reproduce it now without an external display anymore - it seems it's really related to the Intel drivers after all.

Is everybody using Intel hardware/drivers? Do you use external displays? If so, does it happen on each of them?

[pmav99]

Update: Both on my desktop and my laptop I am using these drivers:

$ pacman -Qs xf86-video-intel
local/xf86-video-intel 1:2.99.917+770+gcb6ba2da-1 (xorg-drivers)
    X.org Intel i810/i830/i915/945G/G965+ video drivers

AFAI know/remember, I have not made any changes (e.g. xorg.conf etc).

My Desktop's has an HD4600 while the laptop has an HD 530.

I don't use an external display, but If you think it will help in debugging I can connect one. Nevertheless, I can reliably reproduce the problem on both machines using awesome >= 4.0 while there is no problem on awesome 3.5.9.

[blueyed]

Just an idea: maybe size_hints_honor is relevant here? (I am using false by default). See https://awesomewm.org/apidoc/documentation/90-FAQ.md.html.

[teranex]

@blueyed size_hints_honor seems to be relevant yes (see also my previous comment https://github.com/awesomeWM/awesome/issues/1668#issuecomment-289318734). When I set it to false Gvim has problem, although on 4.1 i experienced less problems than on 4.0. Now I have set it to true for Gvim (and false in my default rule) and haven't had any problems with Gvim these past 2 weeks or so.

[pmav99]

I've tried to set size_hints_honor both to true and false but there is no change. Running on current master.

[pmav99]

OK, I did some more checking. It does seem to be vim-related after all...

Note: the bug is only triggered when creating vertical splits. I.e. ctrl + W + v. Horizontal splits work just fine.

I noticed that gvim -u NONE (which means run gvim without loading ~/.vimrc) does NOT trigger the bug, so I started to bisect my .vimrc in order to find the culprit. And... the line that causes the problem is set splitright. Removing this line seems to stop the bug from triggering.

I would really appreciate If someone could also confirm that this is causing the problem.

[sriedel]

@pmav99 I don't have splitright set and I see the bug. However it sometimes takes an hour or so for the bug to appear for me, so just because it doesn't happen within 5 minutes don't assume that you're home free :)

[pmav99]

You are right, I will keep checking. Could you also please try gvim -u NONE and see if the bug gets triggered?

[blueyed]

@pmav99 I don't have 'splitright' set, but could reproduce it easily after :vsp - but only with the external display initially. Now I can be trigger it again, both with gvim -u NONE and (not as easily though) using my config. However, it needs size_hints_honor = false in Awesome to trigger it (which I use globally).

With my config I need to :vsp, :q and :vsp again - where gvim already has some display glitches.

Bisecting now again..

[blueyed]

Found it:

baaff93a7349a9da67b4b8f291a62820828f14bd is the first bad commit commit baaff93a7349a9da67b4b8f291a62820828f14bd Author: Uli Schlachter Date: Thu Sep 15 18:48:56 2016 +0200

Only configure client geometries once per main loop iteration

This should "protect" the user from some stupidities that Lua code might be
doing that e.g. makes a client jump to another position and then immediately
back to where it was before. Only the last change in a single main loop
iteration will actually have any effect.

Original idea by Daniel here: https://github.com/awesomeWM/awesome/pull/174

Signed-off-by: Uli Schlachter <psychon@znc.in>

/cc @psychon

[psychon]

@blueyed No idea. I suggest adding some warn("configuring %s to %dx%d, %dx%d", c->name, c->geometry.x, c->geometry->y, c->geometry.width, c->geometry.height); at "the right places" before and after that commit and see what difference is visible. Another idea would be to add xcb_configure_window(globalconf.connection, c->window, XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT, (uint32_t[]) { 42, 42 }); before the other calls to `xcb_configure_window and see if that helps.

If you want me to guess: Some bug in GVim or Gtk (that is only triggered when the WM ignores the size hints (which only awesome does, I think)) that sometimes delays redraws indefinitely.

[Elv13]

If you want me to guess: Some bug in GVim or Gtk (that is only triggered when the WM ignores the size hints (which only awesome does, I think)) that sometimes delays redraws indefinitely.

And because before that commit, the geometry would flicker due to the way arrange vs. all the signal callbacks, the problem was hidden because if the 2 extra redraw caused by the flicker. Makes sense.

[sriedel]

It looks like the gvim version bundled with arch still uses GTK+2. Does anyone of the people here who see bug have a gvim version built with GTK+3? This might narrow down if the real culprit is in GTK or gvim.

[pmav99]

@sriedel I just built gvim with gtk3 support instead of gtk2 and the bug has not been triggered so far. I will keep testing it.

edit

Aparrently, Arch reverted back to gtk2 back in october due to https://github.com/vim/vim/issues/1199 https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/vim&id=fdb6b85002ceb59c4d43cd1d0b2c58efa5f98c6d

[pmav99]

I've been using gvim compiled with GTK3 for two days now and there have been no problems whatsoever. I would be really grateful If someone else could confirm that it is indeed a GTK2-related bug

[psychon]

I would be really grateful If someone else could confirm that it is indeed a GTK2-related bug

I just installed vim-gtk (Debian testing here) and could reproduce the bug five times out of five attempts (start vim-gtk, start gvim via :gui, do :vsp, switch to another tag and back). The same test with vim-gtk3 did not reproduce the bug in five attempts.

Edit: Cannot reproduce under Xephyr (0 out of 5 attempts), so cannot bisect (first comment claims this is a regression) Edit: CAIRO_DEBUG=xrender-version=-1.-1 in the env does not seem to make a difference. Edit: size_hints_honor=true makes the problem go away. Edit: ... and in xtrace I see that gvim is trying to resize its window (I guess to enforce its size hints), but awesome rejects this and does not resize the window (since I'm on a maximized layout). So I guess the bug is "quite old" and was now made visible by baaff93a7349a and 5dc88da3bda3f8626d (before that, awesome would first resize GVim's window and then immediately resize it back to fullscreen). Obviously, reverting that commit is not an option. However, I doubt that anyone from GVim/Gtk has much interest in debugging a problem which only occurs when the WM ignores WM_NORMAL_HINTS.

Can we add an awful.rules-rule to the default config that makes us honor size hints for GVim and close this?

[blueyed]

Can we add an awful.rules-rule to the default config that makes us honor size hints for GVim and close this?

Seems sensible to me, given your investigation.

[sriedel]

@blueyed, @psychon : I really disagree, since I get the issue no matter what I set for the size hints honor rule for gvim.

I'm going to install a gvim built with GTK3 and see if the issue crops up for me during the next week. Since I work in this setup extensively and the bug (if it happens) ususally crops up within half a work day, if it doesn't appear within a few days it'll probably be related to gtk2/gtk3.

[psychon]

@sriedel Try running sleep 1 ; awesome-client 'return client.focus.size_hints_honor' in a terminal and switching to GVim to see if awesome really is honoring size hints for GVim or if you perhaps have a typo. Also, in my case the :vsp already causes some visual corruption since the new scrollbar is not drawn correctly. Perhaps there is more than one issue here?

[blueyed]

in my case the :vsp already causes some visual corruption since the new scrollbar is not drawn correctly

Same for me.

[sriedel]

@psychon, @blueyed It's definitely two different issues, since the issue with the scrollbar after a :vsplit has been existing for me since Awesome 3.0, while the discussed corruption is new with Awesome 4.0. :)

Btw, I've been using a gvim built with gtk3 for about a day now, and the issue completely disappeared, all other things being equal (especially rc.lua). I'm putting my money on an issue with gtk2. @pmav99

[ziggystar]

I'm on Ubuntu with awesome 4.0. I also suffer from redrawing problems in gvim. with vim-gtk3 I had blank screen on startup of gvim. I've switched to vim-athena and at least at startup gvim paints. Still I suffer from occasional redraw failures when switching back from other tags, which I solve resizing gvim slightly. I have to try :redraw!, yet.

I'm also using Intel integrated graphics.

[ziggystar]

Update

• I have a GPU now, and the bug still appears. So my issue is probably not driver related
• I'm not on maximized layout. Still when switching back from another tag, sometimes GVim is not redrawn

[blueyed]

@ziggystar Does :redraw! (with a bang) help then?