On 2006-08-24, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:
> Gary Johnson wrote:

> > I found another problem, though.  Following my previous example and 
> > proceeding from
> >
> >    $ vim -N -u NONE
> >
> > I execute the following commands and the cursor moves to the file 
> > indicated.
> >
> >    +-----------------+-----------------+
> >    | Command         | Resulting       |
> >    |                 | Cursor Location |
> >    +=================+=================+
> >    | :Explore **/*.c | arabic.c        |
> >    |                 |                 |
> >    | :Nexplore       | auto/pathdef.c  |
> >    | :Nexplore       | buffer.c        |
> >    | :Nexplore       | charset.c       |
> >    | :Nexplore       | diff.c          |
> >    |                 |                 |
> >    | :Pexplore       | diff.c          |
> >    | :Pexplore       | diff.c          |
> >    | :Pexplore       | auto/pathdef.c  |
> >    | :Pexplore       | arabic.c        |
> >    +-----------------+-----------------+
> >
> > So there seems to be a "pointer" traversing an internal list of 
> > files that is moved by the :Nexplore and :Pexplore commands.  The 
> > :Nexplore and :Pexplore commands both control this pointer 
> > correctly, but only the :Nexplore command updates the cursor 
> > location correctly, unless the directory is changed.
> >  
> >
> I'm seeing the cursor move to the next/previous matching file for both 
> :Nexplore and :Pexplore.

That's really weird.  I see the same broken :Pexplore behavior with 
both my SunOS and Linux versions.  Maybe the problem has been fixed
with a patch.

----------
VIM - Vi IMproved 7.0 (2006 May 7, compiled May  8 2006 16:40:23)
Compiled by [EMAIL PROTECTED]
Normal version with GTK 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 +fork() -gettext -hangul_input -iconv 
+insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent 
+listcmds +localmap +menu +mksession +modify_fname 
+mouse +mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm 
+mouse_xterm -multi_byte +multi_lang -mzscheme 
+netbeans_intg -osfiletype +path_extra -perl +postscript +printer -profile 
-python +quickfix +reltime -rightleft -ruby 
+scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax 
+tag_binary +tag_old_static -tag_any_white -tcl 
+terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit 
+virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim 
+xsmp_interact +xterm_clipboard -xterm_save 
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/home/garyjohn/src/SunOS/vim-7.0/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  
-I/opt/TWWfsw/gtk+12/include/gtk-1.2 -I/opt/TWWfsw/glib12/include/glib-1.2 
-I/opt/TWWfsw/glib12/lib/glib/include -I/usr/openwin/include 
-I/home/garyjohn/src/SunOS/ncurses-5.4/include/ncurses  -g -O2  
-I/usr/openwin/include       
Linking: gcc  -L/usr/openwin/lib -R/usr/openwin/lib   
-L/home/garyjohn/src/SunOS/ncurses-5.4/lib -o vim   -L/opt/TWWfsw/gtk+12/lib 
-R/opt/TWWfsw/gtk+12/lib -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk 
-L/opt/TWWfsw/glib12/lib -R/opt/TWWfsw/glib12/lib -lgmodule -lglib -lXext -lm 
-lXt -lX11 -lSM -lICE -lnsl -lsocket  -lncurses -ldl        
----------

s I do see one odd behavior, however:  :Nex doesn't move the cursor, 
> instead a vim error gets
> issued: "E163: There is only one file to edit".  :Nexp (and longer) 
> works.  There are two commands
> that also begin with :Ne... (:NetUserPass and :NetrwSettings) which I 
> assume are causing this
> behavior.  Perhaps its a vim bug?

I've been spelling them out in full just to be sure.

Regards,
Gary

-- 
Gary Johnson                 | Agilent Technologies
[EMAIL PROTECTED]     | Wireless Division
                             | Spokane, Washington, USA

Reply via email to