On Sun, 13 Aug 2006 at 11:42pm, Eddy Zhao wrote: > Hi Hari: > > I tested the new plugin, most new features works as expected. Some > problems found, > see comments below: > > - Backspace will delete the whole path, it's better it delete the > directory path > back only to the previous path delimiter > > - Press TAB, delete path to parent directory, find > directory-content-window doesn't popup (it > might because path delimiter is "\", not "/", it's better to popup > all files in the > parent directory at that time)
Both of these are related/same, I am not going to support \ as path separator, since it also needs to be supported to protect meta characters. This also reduces confusion and complexity. Just use forward-slash consistently in both windows and unix. I don't see ido.el recognizing \ either, at least with the default configuration. > - Press TAB, delete path to parent directory, press TAB, find TAB is > inserted as TAB character. > It's better to universally use TAB as > directory-content-display-command in lookup window, and > never insert it as TAB character <Tab> in ido.el results in showing the mini buffer (the one with the full matches). We don't have that problem here, as the matches are not limited by screen real estate. I don't actually see a need to press <Tab>, unless you are habitual, in which case you can map it yourself in your ftplugin to whatever you want. > - Press TAB, delete path to parent directory, enter filename keyword, > find file-match-window > doesn't popup (it might because path delimiter is "\", not "/") This is same as the first two. Try changing the "\" to "/" immediately and see if the popup comes up with any matches. > - Press TAB, C-b, find a lot of error message I can't reproduce this problem, though I see an issue with <C-B> when there is no token typed yet (only path), which I Will fix. Can you give me reproducible steps, and also copy the error messages and send them? > - Press TAB, Esc Esc, LUBufs, find lookup window contain previous path info The previous pattern is shared for all modes. If you want to always start empty, use :LUBufs!. You can create a custom command for this, and use that instead of remembering to suffix with bang. > Some more features seems to be useful > > - TAB could also used to show all buffers at LUBufs window It is not possible to show matches without having anything typed (a limitation of Vim popup completion). You can press a single "." to match with all the buffer names (the match is done using Vim regex). > - There's a plugin called MRU.vim, it saves files most recently used > in file named "_vim_mru_files". > I use this plugin extensively. May be lookupfile could also make > use of it, and to provide a > consistent file locating frontend for directoryfile, mrufile, buffer. I am not going to promise any support for this soon. I don't use this plugin as I use my selectbuf plugin which already provides the MRU ordering of buffers. You are free to add support and send me a patch :) > Thanks for take time look into that > Eddy If you can send me the steps to reproduce the errors with <C-B>, I can fix it and finalize this release. Thanks for all your feedback and testing. -- Thanks, Hari > > 2006/8/13, Eddy Zhao <[EMAIL PROTECTED]>: > > Hi Hari, > > > > Sorry for the late response (been busy at some family stuff). I'll > > try the new version > > very soon and post the feedback. Thanks for you quick response and > > great work (being happily maintain my large wiki docbase using your > > lookupfile plugin now :) > > > > Thanks > > Eddy > > > > 2006/8/13, Hari Krishna Dara <[EMAIL PROTECTED]>: > > > > > > Give the new version a try, I uploaded it to the below URL: > > > > > > http://haridara.googlepages.com/lookupfile.zip > > > > > > Here are the improvements for LUWalk command: > > > - g:LookupFile_AlwaysAcceptFirst setting to always accept the first > > > entry (set it to 1, the default is 0). > > > - g:LookupFile_FileFilter to specify a filter. Ex: > > > let g:LookupFile_FileFilter = '\.o$\|\.so$\|\.exe$' > > > - LUWalk command accepts the initial directory as argument. This > > > provides a number of possibilities to create your own custom commands > > > (see |lookupfile-tips| for some examples). > > > - Pressing <Tab> first time, fills up the directory of the current > > > buffer. > > > - You can now use <BS> to remove the entire directory component at a > > > time. This applies to insert mode only. > > > - Pressing <CR> on directory works as expected. Instead of opening the > > > directory, it now selects it, and updates the matches for that > > > directory, so navigation is much faster when you get unique matches. > > > - You can also press <C-F> and <C-B> to switch between file and buffer > > > modes. > > > - The g:LookupFile_MinPatLength is automatically set to 0 (this really > > > makes sense only for tag lookup and 'path' search). > > > - Enclose matching pattern in "[]". > > > - You can now create ftplugin/lookupfile.vim, and put commands such as: > > > nnoremap <buffer> <Esc><Esc> <C-W>q > > > inoremap <buffer> <Esc><Esc> <Esc><C-W>q > > > > > > Regarding your below points: > > > > > > > - prefix filename with ">" (or something else) will searching file > > > > recursively in the current directory > > > > > > It is already possible by specifying "**" as a path component. Try it > > > out. > > > > > > > - order matching files by mru first, file already visible in the frame > > > > at end (ido feature) > > > > > > I don't see any specific order while using ido, and this makes sense > > > only while showing the buffer list. I already have a TODO to support > > > other types of sorting, so I am not going to do this for now, and I > > > think this is not that big of a deal for its usability. > > > > > > Also go through the help file, it has a number of tips and other useful > > > information to customize and extend without much effort. Please send me > > > your feedback. > > > > > > -- > > > Thanks, > > > Hari > > > > > > On Fri, 11 Aug 2006 at 2:33pm, Hari Krishna Dara wrote: > > > > > > > > > > > On Fri, 11 Aug 2006 at 1:31pm, Eddy Zhao wrote: > > > > > > > > > Hi Hari: > > > > > > > > > > I tried the new plugin. Excellent! Exactly what I want. There are > > > > > several missing features I think could make lookupfile even more > > > > > effecient & useful. Can you evaluate these features also ? > > > > > > > > > > - include opened buffer as matching target (ido feature) > > > > > > > > The LUBuf command already does this. Is this not good enough for you? > > > > The ido feature doesn't seem to restrict the list to any directory, so I > > > > think LUBuf is what you want. (Did you actually read through the help > > > > file?) > > > > > > > > You can switch from one mode to another (LUBufs to LUWalk) by creating > > > > separate mappings. I will add support for defining "lookupfile" > > > > ftplugins so that you can create such custom mappings to your liking. > > > > > > > > > - order matching files by mru first, file already visible in the frame > > > > > at end (ido feature) > > > > > > > > This requires some work, but can be done. I will most probably take > > > > advantage of one of my other plugins that maintain and expose MRU list > > > > (SelectBuf), to reduce work and duplication. This means you will need to > > > > install SelectBuf as well. > > > > > > > > > - one enter keystroke will open the first matching file in the matching > > > > > list (this scenario happens frequently, ido feature) > > > > > > > > Currently this is done when there is only one match (by choice). I can > > > > create an option so that it can always open the first one. > > > > > > > > > - backspace will delete the directory path back to previous path > > > > > delimiter (filename is still deleted char-by-char, ido feature) > > > > > > > > I observed this too, but was not sure how you can then correct the path, > > > > as you are loosing the <BS> functionality. How does ido deal with this? > > > > > > > > > - default searching directory is based on file most recently used > > > > > > > > You mean, the directory of the last opened file? > > > > > > > > > - open the lookup window and pressing tab (no keyword is entered > > > > > yet) will display files in the current directory (and buffers > > > > > currrently opened) > > > > > > > > I observe that a number of misc. features provided by ido requires a bit > > > > of reworking on the part of lookupfile plugin. E.g., the existing > > > > support for extending the core functionality is not sufficient to treat > > > > <Enter> differently for directories and filenames. I already started > > > > adding a handler support for <Enter>, but it will take some effort to > > > > fine tune this. > > > > > > > > > - double ESC could close the lookup window > > > > > > > > This could be a user map. Once lookupfile ftplugin is supported, you can > > > > put this in your ftplugin file, something like: > > > > > > > > nnoremap <buffer> <Esc><Esc> <C-W>q > > > > inoremap <buffer> <Esc><Esc> <Esc><C-W>q > > > > > > > > > - prefix filename with ">" (or something else) will searching file > > > > > recursively in the current directory > > > > > > > > I am not sure about this. > > > > > > > > > - provide option to filter out some of the files when matching > > > > > (eg. *.o, *.so ... ) > > > > > > > > It should be easy enough to support a user filter regex. > > > > > > > > > - using "[]" instead of "**" to enclose pattern in the matched filename > > > > > > > > I think [] is more easier on eyes. However, ido doesn't seem to be > > > > highlighting the matching text for me, is this a feature that you have > > > > to enable? The hightlighting that I see is: > > > > - first item is in bold > > > > - directories are in red > > > > - unique match is in green > > > > As I said before, these can't be shown using Vim popup support. > > > > > > > > > Thanks for looking into this > > > > > Eddy > > > > > > > > You are welcome. > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > http://mail.yahoo.com > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com