search

murisfurder / vim

Automatically exported from code.google.com/p/vim
0 stars 0 forks source link

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

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 

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

GoogleCodeExporter commented 9 years ago 
Is this still reproducable?

Original comment by chrisbr...@googlemail.com on 30 Sep 2014 at 6:38

GoogleCodeExporter commented 9 years ago 
Still reproducible with Linux Mint (LMDE with MATE) stock package (7.4, 
--version saying includes patches 1-52) or my own build (7.4 from official dl 
site, same configure option).

Additional comments:
1. More likely to occur when navigating with Ctrl-F/Ctrl-B, leaving at least 
half of the screen blank.
2. Only gvim is affected. vim is fine.

Original comment by fancymo...@fancymouse.net on 23 Nov 2014 at 2:15

GoogleCodeExporter commented 9 years ago 
I can reproduce the issue. Unfortunately, I do not know, why patch 7.3.638 
should cause the issue. It looks to me, like the gtk drawing libraries are not 
updating the window correctly, because if I see this correctly, Vim requests 
redrawing of the complete buffer content. I do not know gtk good enough to 
propose a fix though.

Original comment by chrisbr...@googlemail.com on 24 Nov 2014 at 9:58

GoogleCodeExporter commented 9 years ago 
You might want to report that bug also to the Mate developers, because it seems 
to be Mate specific (or does it happen with other desktop environments?).

Nevertheless, Here is a simple patch, that forces a redraw in the gtk gui, that 
seems to work around the problem. Nevertheless, it would be good, if a 
developer with a more found GTK background could have a look at that issue (and 
my patch).

Original comment by chrisbr...@googlemail.com on 25 Nov 2014 at 6:31

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for the patch. Although with your patch as is, Ctrl-F/B still breaks. 
But after I comment out "if (type >= NOT_VALID)", it now looks good to me.

Original comment by fancymo...@fancymouse.net on 5 Dec 2014 at 12:04

GoogleCodeExporter commented 9 years ago

Original comment by chrisbr...@googlemail.com on 9 Jan 2015 at 12:18

GoogleCodeExporter commented 9 years ago 
May not be a Mint specific problem... just got a chance to have a try from 
Debian Testing (jessie rc1) and it's even worse. The patch still works.

Original comment by fancymo...@fancymouse.net on 10 Mar 2015 at 10:23

GoogleCodeExporter commented 9 years ago 
The problem with this approach is, it will make Vim a whole lot slower, since 
what it really does it always force a complete redraw. That is most certainly 
not what is wanted.

Original comment by chrisbr...@googlemail.com on 11 Mar 2015 at 6:17