Chuck Mason wrote:
A coworker (who is not on VIM Mailing List) has asked me to forward this
issue here. Is this already known about or what do we do to submit a
bug?
I have verified that it happens on my build of vim. His repro steps are
below. My :version is
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:23:43)
MS-Windows 32 bit GUI version with OLE support
Compiled by [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
+netbeans_intg +ole -osfiletype +path_extra +perl/dyn -postscript
+printer -profile +python/dyn +quickfix
+reltime +rightleft +ruby/dyn +scrollbind +signs +smartindent -sniff
+statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white +tcl/dyn -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: cl -c /W3 /nologo -D_MT -MT -I. -Iproto -DHAVE_PATHDEF
-DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32
-DWINVER=0x0400 -D_WIN32_WINNT=0x0400 /Fo.\ObjGOLYTR/ /Ox -DNDEBUG
-DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -DDYNAMIC_ICONV
-DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL
-DDYNAMIC_TCL_DLL=\"tcl83.dll\" -DDYNAMIC_TCL_VER=\"8.3\" -DFEAT_PYTHON
-DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python24.dll\" -DFEAT_PERL
-DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl58.dll\" -DFEAT_RUBY
-DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=18
-DDYNAMIC_RUBY_DLL=\"msvcrt-ruby18.dll\" -DFEAT_BIG /Zi /Fd.\ObjGOLYTR/
Linking: link /RELEASE /nologo /subsystem:windows /incremental:no
/nodefaultlib:libc advapi32.lib shell32.lib gdi32.lib comdlg32.lib
ole32.lib uuid.lib oldnames.lib kernel32.lib gdi32.lib version.lib
winspool.lib comctl32.lib advapi32.lib shell32.lib /machine:i386
/nodefaultlib libcmt.lib oleaut32.lib user32.lib
/nodefaultlib:python24.lib e:\tcl\lib\tclstub83.lib WSock32.lib
e:\xpm\lib\libXpm.lib /PDB:.\ObjGOLYTR/gvim.pdb -debug-- INSERT --
<<<
Chuck
_____________________________________________
From: Boris Kazanskii
Sent: Wednesday, April 04, 2007 2:43 PM
To: Chuck Mason
Subject: :args -> buffer list mapping issue
:args allows to insert directory browser buffers into the buffer list,
which cause :bn, :bufdo and friends to fail
To reproduce:
- Open vim (win32)
- :args D:\Program\ Files\Vim\**\co*.* (or whatever matches your
configuration)
- :bfirst
- do a couple of :bn, this will never ever get over the first
directory browser buffer (D:\Program\ Files\Vim\vim70\colors\ in this
case)
- :bufdo echo expand("%") will also stop after it encounters the
first directory browser
- :bd/:bw are unable to delete these "bad" directory buffers
- the only way to get rid of these is to do :1,1000bd
- Even without :args, a netrw buffer gets into the buffer list (but as an
unlisted nofile buffer). This is normal.
- bw does get rid of it if you postfix the buffer number as seen in the output
of ":ls!". No need to wipe out everything. I suppose :bd <number> would make
it unlisted.
- Which version of netrw are you (or Mr. Kazanskii) using? I do NOT experience
the bug with the following:
$VIMRUNTIME/plugin/netrwPlugin dated Jan 05, 2007
$VIMRUNTIME/autoload/netrw.vim version 108 dated Mar 21, 2007
$VIMRUNTIME/autoload/netrwFileHandlers.vim version 9 dated May 30, 2006
$VIMRUNTIME/autoload/netrwSettings.vim version 9b ASTRO-ONLY dated Jan 05, 2007.
These are (AFAIK) the latest versions from the ftp.vim.org site. If you don't
update your vim runtime files, don't be surprised if bugs in them don't
disappear as by magic.
What I experience with the above versions when trying to reproduce the failure
by following Mr. Kazanskii steps is that Vim loads the "colors" directory in
answer to the ":args" command, then the "compiler" directory in answer to
":bfirst", and then cycles through all non-directory files as I enter ":bn"
repeatedly. No error. ":ls!" shows that both directories are still in the
buffer list, but as "unlisted" buffers, one at the top of the list and the
other at the end.
Best regards,
Tony.
--
Remember, UNIX spelled backwards is XINU.
