On Tue, Jul 8, 2008 at 9:32 PM, Dominique Pelle wrote:
> Hi,
>
> I observe a bug in the omni completion popup menu when doing omni
> completion at the end of a line which is longer than the terminal
> width and with "set nowrap". The menu is not drawn at the correct
> location when pressing <Down> when trying to select an item in the
> popup menu.
>
> Bug happens in both Vim and gvim version 7.2a.19 BETA.
>
> Steps to reproduce:
>
> 1/ Install OmniCppComplete script located at:
>
> http://www.vim.org/scripts/script.php?script_id=1520
>
> 2/ Download the c++ sample source file "bug-omni.cpp":
>
> $ wget http://dominique.pelle.free.fr/bug-omni.cpp
>
> 3/ Build a tag file with:
>
> $ ctags --language-force=c++ --c++-kinds=+p \
> --fields=+iaS --extra=+f+q bug-omni.cpp
>
> 4/ Create a minimalistic simple_vimrc file:
>
> $ cat simple_vimrc
>
> filetype plugin on
> set nocompatible
> set columns=80
> set nowrap
> set tags=tags
>
> 5/ Start vim with:
>
> $ vim -u simple.vimrc bug-omni.cpp
>
> 6/ Append s-> at the end of line 10 (the line with a long comment).
> In Normal mode:
>
> 10GAs->
>
> After pressing -> the omni menu should popup up (at correct location).
>
> 7/ Press <Down> to browse though items in menu and observe that menu is
> then re-drawn at incorrect location, at bottom of screen, corrupting
> the content of the screen) as shown in the following screen shot:
>
> http://dominique.pelle.free.fr/bug-omni.png
>
>
> I can try to debug it when I have time during the weekend but perhaps
> someone can reproduce it and fix it before that.
>
> -- Dominique
I investigated this bug a bit, but it's does not look simple.
I have a workaround though.
First of all, the pum is not only displayed at the wrong place,
but depending on the window size and length of the line,
bug can actually cause crash (seg fault).
The following change makes it work (but it's only a workaround):
===================================================================
RCS file: /cvsroot/vim/vim7/src/move.c,v
retrieving revision 1.10
diff -c -r1.10 move.c
*** move.c 5 May 2007 17:35:47 -0000 1.10
--- move.c 9 Jul 2008 19:39:10 -0000
***************
*** 885,891 ****
colnr_T col;
validate_virtcol();
! if (!(curwin->w_valid & VALID_WCOL))
{
col = curwin->w_virtcol;
off = curwin_col_off();
--- 885,891 ----
colnr_T col;
validate_virtcol();
! /*if (!(curwin->w_valid & VALID_WCOL))*/
{
col = curwin->w_virtcol;
off = curwin_col_off();
It looks like curwin->w_valid is marked as valid, when it's not
valid. So the above changes forces to recompute curwin->w_wcol
regardless of the valid status. It's not the right way to fix it (it
might slow down vim) but it may help to debug further.
I came up with this because the value of curwin->w_wcol are
different in popupmnu.c:73 the first time pum_display() is called
(i.e. when pum is at correct place on screen) and the second
time it's called when selecting element in pum (and when pum
is no longer at correct place, corrupting the screen):
- The first time, curwin->w_wcol is marked invalid,
so validate_cursor_col() call at popupmnu.c calculates it
correctly.
- The second time pum_display() is called, curwin->w_wcol
is already marked as valid so call to validate_cursor_col() does
not recalculate it (but the value looks actually incorrect somehow,
hence pum displayed at wrong location). Forcing to recalculate
it works around the bug.
Interestingly, the comment of the function validate_cursor_col()
where I put the workaround says...
move.c:
878 /*
879 * validate w_wcol and w_virtcol only. Only correct when 'wrap' on!
880 */
881 void
882 validate_cursor_col()
883 {
Ah! This bug happens precisely when 'wrap' is off. The piece of
code is complex and I don't understand everything yet, but hopefully
the workaround can help to come up with a proper fix.
-- Dominique
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
