* Bram Moolenaar <[EMAIL PROTECTED]> [060418 12:41]:
> > I found some bugs or strange behaviour with vim7d03, I have made all my
> > tests starting vim with -u NONE -i NONE options, with the terminal
> > version:
> >
> > 1/ When background is set to light, the current selection in the
> > completion popup menu is printed white on white.
> Are you using a B&W terminal? No, then you would not get a popup menu
> at all. In a color terminal the color should be black on grey. I can't
> imagine it's different for you.
> > 2/ When background is set to dark, the current selection in the
> > completion popup menu is printed white on black, but black is the
> > background color, so it is not easy to make the distinction between the
> > text and the menu.
> It's white on grey for me. Do you perhaps have defined different colors
> for your terminal? Vim cannot know about this, thus you will have to
> setup a colorscheme.
I tried using differents terminal, aterm and xterm with default or -bg
black -fg grey60 options, same problem.
But finaly, I managed to make it work as expected if t_Co=16. Default
on my system (debian sarge) seems to be 8. I am not sure where this
value is taken.
I have read this in /etc/vim/vimrc :
" We know xterm-debian is a color terminal
if &term =~ "xterm-debian" || &term =~ "xterm-xfree86"
set t_Co=16
set t_Sf=^[[3%dm
set t_Sb=^[[4%dm
endif
But it is no used as $TERM is xterm with xterm and rxvt with aterm.
> [...]
> > 5/ with longest,menu in completeopt, I do not manage to reproduce it
> > but sometime, vim enter a endless loop, with the message "search hit
> > BOTTOM, continuing at TOP" (it was on vim7d).
> I can't guess how to reproduce this...
I will try to identify how o reproduce it. Perhaps there is a problem
in a loop exit condition in vim code?
> > With longest, without menu:
> >
> > 6/ When I type ^X^P^P, the second item is selected, but the first one is
> > never selected, I have to press ^X^P^P^N to see it. It could be better
> > to have a state where there is no item selected and vim displaying
> > "longest" in the command line instead of "match 1 of x".
> It's probably better to stick to the original text. I'll see if that
> can be done.
What do you mean? What I beleave could be best is a behaviour similar
to the wildmenu completion. For exemple :
aaaa
aabb
a<-- here I press ^P, first time it should be completed as "aa", then if I
press ^P again, "aabb", then "aaaa", then original "a", then "aabb"...
> [...]
> > 8/ ^L and ^Y do not seem to work when menu is not in completeopt.
> That is right. They don't make much sense when you can't see the text
> of the current completion.
Ok. Perhaps the doc should be change in 'completeopt' from:
longest Only insert the longest common text of the matches. Use
CTRL-L to add more characters. Whether case is ignored
depends on the kind of completion. For buffer text the
'ignorecase' option is used.
to:
longest Only insert the longest common text of the matches.
If the menu is displayed, use CTRL-L to add more
characters. Whether case is ignored depends on the
kind of completion. For buffer text the
'ignorecase' option is used.
> > Last ones which is not related to text completion:
> > 9/ In visual mode, pink text is unreadable when selected.
> Don't use pink text! :-) See the remark about using a colorscheme
> above.
But there is pink text in the default colorsheme! I mean magenta
actually :-) I have the same problem with diffmode.
> > 10/ In command line completion, with "set wildmenu
> > wildmode=longest:full,full", when the command line is completed to the
> > longest, the first item is selected in the wildmenu.
> What do you mean with "completed to the longest"?
If I have a directory with the files aaaa and aabb, then the first tab
complete to aa, then if I press it again, it is completed to aaaa, then
aabb. Nice. But the first time I press tab, the first item in the
wildmenu is highlited which is quite confusing because the user can beleave
that the first item is selected.
Nicolas.
