* Bram Moolenaar <[EMAIL PROTECTED]> [060418 15:28]: > > > > 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. > It is a common problem that the $TERM value is xterm while you are > actually using a color xterm. Vim does check the actual number of > colors supported if the t_RV value is set. Unfortunately this is not a > generic mechanism, only works for xterm. > Adding another set of default colors for when t_Co is 8 would be quite a > bit of work...
What about choosing colors available with both 8 and 16 colors? Or using reverse video? > > > > 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"... > I now changed it to work like that (mostly). > You an use CTRL-L to add another character. Hmm, my change not to use > the first match actually broke that, you now need to do CTRL-N or CTRL-P > first. Perhaps a different behaviour could be used for longest,menu and longest. I am not sure if it is better or not. Any other opinions? > [...] > > > > 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. > I suppose we need to fall back to reverse when there are only 8 colors. > Try the patch below. Looks ok for me, but it does not solve the more general problem that with vim7, many colors can not be used for text highliting if there are also used in visual mode or diff mode for bg color. > [...] Nicolas.
