You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem is not present in tag v7-3-637. Problem appeared first in tag v7-3-638.
What steps will reproduce the problem?
Using gvim:
1. Go to v7-3-638 vim source directory
2. File->Open and select Filelist
3. Content shows correctly
4. File->Open and select README.txt
5. Contents are not updated, section of Filelist still shows
6. Move mouse wheel or cursor, contents are now updated correctly
What is the expected output? What do you see instead?
Exepcted output is content of newly opened file. I see part of old file until
screen refreshes by moving cursor.
What version of the product are you using? On what operating system?
Linux Mint 13 with MATE 1.2 or 1.4
gvim compiled from source with: ./configure --enable-gui=gtk2
--enable-rubyinterp=yes --with-features=huge
Kernel: 3.2.0-32-generic #51-Ubuntu SMP
Please provide any additional information below.
Problem is not present in tag v7-3-637. Problem appeared first in tag v7-3-638.
Original issue reported on code.google.com by yerv...@gmail.com on 3 Nov 2012 at 1:33
The text was updated successfully, but these errors were encountered:
I have the same issue as GoogleCodeExporter using VMware Workstation 12.5 and Ubuntu 16.04 patched to latest. Existed in Ubuntu 14 and Workstation 12 as well. Host is a HP Z620. This only occurs on this host all 3 of Ubuntu I am running. Haven't noticed the issue on CentOS. Using --sync option is a workaround.
Roughly speaking, X clients cannot update their window content until a certain event from the X11 server arrives at their event queue and then drives the event loop to invoke the callback function for update.
As for the GTK2 GUI, the callback function for update is quite passive. It is associated with update events at initialization and never dissociated from them until the process terminates. In addition, there’s no code at all in the implementation to block update events at runtime.
Moreover, as indicated in the top post:
Move mouse wheel or cursor, contents are now updated correctly
and in @chrisbra's gtk2_force_redraw.diff, the callback function works as expected once it gets an update event or another event which induces update.
In short, just like any other X clients, the GUI is made not to exercise its veto over any update requests.
Accordingly, it is highly likely that either of the windowing system under a certain environment or the GTK library (or some interaction between them) prevents update events from being delivered to the GUI for the case in question.
If this is the case, there’s nothing left for the GUI to do with.
Original issue reported on code.google.com by
yerv...@gmail.com
on 3 Nov 2012 at 1:33The text was updated successfully, but these errors were encountered: