On Wed, 16 Aug 2006 at 11:08am, Eddy Zhao wrote:

> > >
> > >  - Without "set shellslash", open one file manually, open lookupfile
window,
> > >    the path's backward slash is not replaced by forward slash
> >
> > This is because you are using a custom command that passed an initial
> > path with backslashes. The plugin now takes care of this as well.
> >
>
> Problem solved. There still exist another problem with backslash: open
> one file manually, open lookup window, select another directory from
> directory-content-window, the directory path selected is backslashed.

I didn't realize that glob() listing will be based on 'shellslash'
setting. Sorry, I always have it set, so am not seeing these issues that
you report. I changed the code to explicitly set and reset this setting,
so this should be fixed now.

> > >  - Sometimes, the following error msg popup when open file thru
lookupfile
> > >    (after that file is opened successfully). The problem can't be
reproduced
> > >    everytime (and can't find out how to reproduce it, I haven't seem
> > > this problem
> > >    when using the previous version plugin)
> > >
> > >       Error detected while processing function
> > > <SNR>55_OpenCurFile..<SNR>15_LookupReset:
> > >       line    10:
> > >       E31: No such mapping
> > >       E31: No such mapping
> >
> > I can't reproduce this. David Fishburn reported the same error as
> > something that gets generated while using the <C-B>, so I tried it with
> > several variations with no success. I put in some trace which will give
> > more information, so hopefully I can figure out something the next time
> > it happens to you.
> >
>
> This time error message is
>     Error detected while processing function
> <SNR>64_OpenCurFile..<SNR>33_LookupReset:
>     line      13:
>     0
>     Error detected while processing function <SNR>64_OpenCurFile:
>     line      11:
>     E171: Missing :endif

This weird error is because of incorrectly using "+" to concatenate
strings instead of "." in the :echoerr I put in.

Thanks for the reproducible steps, I understood what was happening. When
you quit window without selecting anything and you reopen the window,
duplicate cleanup commands were getting added, and when they get executed
result in these errors. I have now put in a BufHidden handler to cleanup
automatically, so hiding the window should also cleanup the mode.

> > >  - Sometimes, after I open one file manually, and then open lookupfile
> > window,
> > >    directory path is not updated with the newly opened file's path.
> > > The problem can't be
> > >    reproduced everytime (and can't find out how to reproduce it,
> > > previous version plugin
> > >    also have this problem)
> >
> > The path is not based on the latest file, but the buffer that you are
> > currently in. This is how ido seems to behave. Try ido with two split
> > windows containing files from different directory. The path that it
> > starts with is set to the directory of the file the current window
> > contains.
> >
> > If you want files from current directory (getcwd()), then you can just
> > start typing (don't press <Tab>).
> >
>
> I think might we are not refer to the same problem. I find way to reproduce
> it: open one file manually, open lookupfile window, delete all the path,
> press TAB (or just start typing), find directory filled is changed to vim
> executable file directory

The path was being filled based on the current buffer, which got changed
to its own buffer by this time, and its directory in your case happened
to be the Vim home directory. I fixed it by saving the original buffer
number locally, so that it can be referred to until it is invoked again
on a different buffer.

> > > New feature request
> > >
> > >  - Directory in showed in directory-content-window is postfixed by
> > > "/", but the "/" is
> > >    too far from the path name. It might be more eye easy to postfix
> > > directory name with
> > >    "/" directly after it.
> >
> > This is how it was before, and I removed it as I thought it is redundant
> > to show the separator in both the name and the "kind" field. I am now
> > showing in both places and it doesn't seem to clutter.
> >
>
> Done.
>
> Thanks
> Eddy

Thanks again for all your feedback. I think we are very close to
wrapping this up.

http://haridara.googlepages.com/lookupfile.zip

-- 
Thanks,
Hari

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Reply via email to