Re: Vim 7.0 (1-109 patches) completion bug.
This was a response to a personal mail from Igor, but I am unable to reach his address by mail. I got my message back with: [EMAIL PROTECTED]: 80.91.16.141 does not like recipient. Remote host said: 553 5.7.1 smtp106.sbc.mail.mud.yahoo.com[68.142.198.205]: Client host rejected: Big domain level Giving up on 80.91.16.141. This continues the conversion with the same subject. There does appear to be a bug. Please read on. On Sun 8-Oct-06 10:42pm -0600, Igor Prischepoff wrote: Hello, Bill. Can you try _one more last time_ please ? gvim - whatever you prefer for clean vim without preferences set cot+=longest set cot-=menuone set complete-=t After starting with: gvim -u NONE -i NONE -N I typed: :se cot+=longest cpt-=t cot cpt Gvim outputs: completeopt=menu,preview,longest complete=w,b,u,i which is hopefully the same state you get. i one : word two : word oC-N:tC-N On the first C-N, 'o' is expanded to 'one', however I get a message Back at original. That is wrong. The original is 'o' not 'one'. Gvim appears confused. Typing any non- whitespace printable characters continues its confusion and another C-N, after typing one or more of these characters, does nothing. After the 'one' is completed from the first C-N, a second C-N changes the message to The only match. Now you can continue typing - the completion text in the command area will be cleared and C-N will work on 't' (but you'll be in the same wrong state of completion with the incorrect message of Back at original. BTW, a C-Y is supposed to tell Gvim you are done with completion. It behaves strangely here. After the C-N completes the 'o' to 'one', a C-Y indeed ends the completion but I am not left with 'one', I am left with 'ow'! what I've got is one : word two : word one:t and message Back at original Please note that when you type C-N first time (after 'o') you should get 'one' expanded automatically because it's only match in this case. And when type C-N after 't' you should get nothing (that's a bug I think). In both cases you should get NO MENU. (because of longest and no menuone in completeoption) I get no menu because there is no menuone, not because of longest. Don't you also see the problem begins with the first C-N after the 'o'? If you got other result's can you please send you :ver output? mine is : vi Improved 7.0 Included patches:1-118 Here the output of :version VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 8 2006 13:02:44) MS-Windows 32 bit GUI version with OLE support Included patches: 1-121 Compiled by Bill McCarthy [EMAIL PROTECTED] Big version with GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang +mzscheme/dyn +netbeans_intg +ole -osfiletype +path_extra -perl -postscript +printer -profile +python/dyn +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl -tgetent -termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save -xpm_w32 system vimrc file: $VIM\vimrc user vimrc file: $HOME\_vimrc 2nd user vimrc file: $VIM\_vimrc user exrc file: $HOME\_exrc 2nd user exrc file: $VIM\_exrc system gvimrc file: $VIM\gvimrc user gvimrc file: $HOME\_gvimrc 2nd user gvimrc file: $VIM\_gvimrc system menu file: $VIMRUNTIME\menu.vim Compilation: gcc -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=pentium3 -Wall -Ic:/util/MzScheme/include -DFEAT_MZSCHEME -DMZSCHEME_COLLECTS=c:/util/MzScheme/collects -DDYNAMIC_MZSCHEME -DDYNAMIC_MZSCH_DLL=libmzsch209_000.dll -DDYNAMIC_MZGC_DLL=libmzgc209_000.dll -DFEAT_PYTHON -I c:/util/python24/include -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=python24.dll -O3 -fomit-frame-pointer -freg-struct-return -s Linking: gcc -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=pentium3 -Wall -Ic:/util/MzScheme/include -DFEAT_MZSCHEME -DMZSCHEME_COLLECTS=c:/util/MzScheme/collects -DDYNAMIC_MZSCHEME
RE: Vim 7.0 (1-109 patches) completion bug.
Thank you, Bill. I can confirm same behaviour as you described with my vim. Now it is up to Bram to decide if this is wrong or right. --- [EMAIL PROTECTED]
Re: Vim 7.0 (1-109 patches) completion bug.
On Fri 6-Oct-06 12:25am -0600, Igor Prischepoff wrote: Well, i still don't understand vim logic behind that process. Let's see more realistic example. gvim -U NONE -u NONE Only last time, although I don't think it matters in this example, you are working in 'cp' mode. Many of vim/gvim features will not work in that mode. (Also, the -U NONE is redundant. See ':h -u' second paragraph for why you don't need -U and the side effect of setting 'cp') 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; oC-N:=tC-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. What action did you take on the first C-N? Since 'o' is the longest common, no addition completion is done. If you just want the 'o' type C-Y, if you want 'one' type C-N, or if you want 'or' type C-P. Why C-Y? See ':h complete_CTRL-Y' Now type ':=tC-N'. What do you mean by still not working? I see (since I picked 'one' for the first completion): one:=t two two_and_three three this Nothing was added to the 't' because it's the longest common. If I now want 'this;' I would type 'C-P;'. My complete keystrokes from insert mode at the beginning of that line are: oC-NC-N:=tC-NC-P;Esc and my line reads: one:=this; and my cursor would be on the ';'. -- Best regards, Bill
Re: Vim 7.0 (1-109 patches) completion bug.
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-=tdon'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 oC-N:tC-Nnow 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
Re: Vim 7.0 (1-109 patches) completion bug.
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 You must mean 'completeopt' here. i now we in insert mode one two oC-N:tC-Nnow 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? Vim is still in completion mode and there is no word matching one:t thus you don't get any completions. If you type CTRL-N one more time then it works. I can see this is unexpected, perhaps when longest is used and there is only one match it should work as if that match was selected with CTRL-N. -- hundred-and-one symptoms of being an internet addict: 4. Your eyeglasses have a web site burned in on them. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Vim 7.0 (1-109 patches) completion bug.
Dnia czwartek, 5 października 2006 05:16, Igor Prischepoff napisał: 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 oC-N:tC-Nnow 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? Confirming it for 7.0.110 (Linux, GTK2). Or it's intended behaviour? I don't think so. Note, when you press space and later return to the end of one:t it works. m.
vim -u NONE (was: Re: Vim 7.0 (1-109 patches) completion bug.)
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 I wouldn't think the -i option is necessary, because 'viminfo' is empty by default anyway. Perhaps there should be a shell script distributed with vim so that anyone can start up vim cleanly. cleanvim.sh: vim -u NONE -i NONE -N --noplugin --cmd 'set rtp=$VIMRUNTIME' '+set rtp' cleanvim.bat: gvim.exe -u NONE -i NONE -N --noplugin --cmd set rtp=$VIMRUNTIME +set rtp regards, Peter On Yahoo!7 Men's Health: What music do you want to hear on Men's Health Radio? http://www.menshealthmagazine.com.au/
Re: vim -u NONE (was: Re: Vim 7.0 (1-109 patches) completion bug.)
On 2006-10-06, Peter Hodge [EMAIL PROTECTED] wrote:
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
I wouldn't think the -i option is necessary, because 'viminfo' is
empty by default anyway. Perhaps there should be a shell script
distributed with vim so that anyone can start up vim cleanly.
cleanvim.sh:
vim -u NONE -i NONE -N --noplugin --cmd 'set rtp=$VIMRUNTIME' '+set rtp'
cleanvim.bat:
gvim.exe -u NONE -i NONE -N --noplugin --cmd set rtp=$VIMRUNTIME +set
rtp
Setting -u NONE -i NONE -N is all that's needed. See :help -u.
When {vimrc} is equal to NONE (all uppercase), all
initializations from files and environment variables are
skipped, including reading the |gvimrc| file when the GUI
starts. Loading plugins is also skipped.
The viminfo file may be empty initially, but it probably is not once
vim has been run.
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
RE: Vim 7.0 (1-109 patches) completion bug.
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; oC-N:=tC-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:=tc-n works as expected. Now vim guesses right about ':' and '=' not being parts of a word, but why not from the first attempt? -- Igor.
Vim 7.0 (1-109 patches) completion bug.
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-=tdon'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 oC-N:tC-Nnow 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? --- [EMAIL PROTECTED]
