Re: completeopt: menu|menuone + longest = bug?

2006-05-01 Thread Bram Moolenaar
Eric Van Dewoestine wrote: I know about this: When you type the . and there no complete match was inserted (showing the longest common text in this example), Vim assumes you are extending the text to reduce the list of matches. Thus the completion still starts at BlahBlah. You need

Re: completeopt: menu|menuone + longest = bug?

2006-05-01 Thread mzyzik
On Tue, May 02, 2006 at 12:13:37AM +0200, Bram Moolenaar wrote: Eric Van Dewoestine wrote: I know about this: When you type the . and there no complete match was inserted (showing the longest common text in this example), Vim assumes you are extending the text to reduce the list of

Re: exists(*Foo!garbage) = 1 ?

2006-05-01 Thread Benji Fisher
On Tue, May 02, 2006 at 12:13:37AM +0200, Bram Moolenaar wrote: Charles Campbell wrote: Bram Moolenaar wrote: The problem of changing something like this is that all scripts that are included in the release need to be checked for effects. And there are lots of scripts now. I

Re: completeopt: menu|menuone + longest = bug?

2006-05-01 Thread Eric Van Dewoestine
It's too complicated already, adding another option will mainly cause more users to get confused. Also, I wouldn't know what to set it to for C. It's not that confusing. This is not a good reason for not implementing something like 'completedelim'. A better reason would be that nobody feels

gvim + X + geometry + set line + cttrl-f + folding (whew!) : a bug

2006-05-01 Thread Charles E. Campbell, Jr.
Hello! This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup: (using Linux,vim-7.0g, huge) .vimrc : set nocp .gvimrc : set lines=21 no .vim/ directory. Now, for the problem: gvim -geometry 139x22+0+4 netrw.vim 11jspace zcr 4jspace6k4j ctrl-f Note that the ctrl-f does not