On Wed 4-Oct-06 10:16pm -0600, Igor Prischepoff wrote:
> Hi, i think i have found a bug in vim 7.0
> Patch level 1-109.
> Windows version +perl +python (i don't think this matters in this case)
>
> here is how to reproduce:
> gvim -u NONE -U NONE
> :set complete-=t " don't want complete from tags file - it's not
> important, just to switch off message
> :set complete+=longest " that's important
> i "now we in insert mode
>
> one two
> o<C-N>:t<C-N>"now trying to complete second time - no completion, nothing"
> i.e. i've got resulting text in buffer like this:
>
> one two
> one:t
>
> and no 'two' on second C-N when trying to complete 'two' and message "Back
> at original"
>
> (First completion works as expected, but second didn't shown and not
> complete at all)
> if remove 'longest' from 'complete' then everything works as expected.
>
> Can you reproduce that bug?
> Or it's intended behaviour?
I see two issues.
The first is independent of adding "longest" to
'completeopt'. Whenever you get "Back at original" in the
command window, typing additional non-whitespace characters
keeps you in a "complete mode" until you either use
whitespace or backspace to the original. I don't see this
behavior documented.
The second, using
:se cot+=longest
causes Vim to complete to the longest common text among the
matches (starting from the beginning) and completes the
typing to that point. Yet it calls this partial completion
"Back at original" even though it clearly is not the
original - so you are back to the first issue.
BTW, using
gvim -u NONE -U NONE
is both redundant (in the case of -U NONE), dangerous (since
default settings may truncate your viminfo on exit), and put
you in vi compatible mode. Better is:
gvim -u NONE -i NONE -N
An even better approach to getting a more virgin Vim is:
gvim.exe -u NONE -i NONE -N --cmd "se rtp=$VIMRUNTIME" "+se rtp&"
That stops making access to personal rtp paths for starting
up, and restores the default rtp at the end of startup.
--
Best regards,
Bill
