Well, i still don't understand vim logic behind that process. Let's see more realistic example. ======================== gvim -U NONE -u NONE Let's suppose that I am a poor pascal programmer and typing code like this: :set completeopt+=longest :set complete-=t i var one : byte; two : byte; two_and_three : byte; three : byte; // may be this is a word? one:=three; // or next one is a a word? one:=two_and_three; o<C-N>:=t<C-n> // completion in second <C-N> still not working here... // so there is no word? not 'one:=t*' or 't*' words in buffer? // I still thinks it should be considered as a bug.
>> Vim is still in completion mode and there is no word matching "one:t" Okay, in above example there is 'one:=three' word specially for vim, but still no completion. And why vim looks for 'one:=t' word? ':' and '=' should not be in the 'word', right? I think that vim should looks for 't' words. Because '=' and ':' is not word, it's not part of identifier. Part of line -may be, but not words. >> thus you don't get any completions. If you type CTRL-N one more time then it works. Sorry,it's not working for me. (1-105 patches) I mean that I'm typing Ctrl-N many times in desperate attempts to get some completion and: no completion absolutely :(. Even when there is multiply matches for t -starting words. And what more strange is that if I'm switching to normal mode and then switch back in insert mode then completion on the same construction one:=t<c-n> works as expected. Now vim guesses right about ':' and '=' not being parts of a word, but why not from the first attempt? -- Igor.
