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
