Eddy, Thanks for the extensive testing. I now uploaded it as version 1.2 to vim.org:
http://www.vim.org/scripts/script.php?script_id=1581 It should be same as what you already have. -- Thanks, Hari On Wed, 16 Aug 2006 at 5:46pm, Eddy Zhao wrote: > > > > 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. > > > > Done. > > > > > > - 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. > > > > Done. > > > > > > - 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. > > > > Done. > > I've been using the new plugin extensively for one hour and didn't find any > problem. Fairly satisfied with the plugin now, thanks for the great work, > maybe time to publish the new version :) > > BTW, don't forget mru-ordering feature and MRU.vim-integration feature if > you find time & interest :) But even without these features lookupfile > is efficient > enough in locating files for me ! > > Thanks > Eddy > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
