Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File->Open does not update window content correctly - Appeared first in v7-3-638 #91

Closed
GoogleCodeExporter opened this issue Aug 18, 2015 · 14 comments

Comments

@GoogleCodeExporter
Copy link


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

@wsdjeg
Copy link

wsdjeg commented Sep 9, 2015

is there any differeces between vim and gvim in ubuntu system,i have navel used gvim.

@benbaez
Copy link

benbaez commented Sep 20, 2016

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.

@nuko8
Copy link

nuko8 commented Sep 20, 2016

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:

  1. 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.

@chrisbra
Copy link
Member

i am closing this, as this is no gvim issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants