Hi Hari:
Problems reported yesterday
- Put the "set shellslash" in vimrc solves most of the backward-slash problems.
May be it's worth mention in the plugin doc.
- I can't reproduce the "Press TAB, C-b, find a lot of error message"
problem today,
I'll report the problem when I find the way to reproduce it.
- MRU.vim provide history to files (not buffers) recently used. It is
especially
useful in switching between serveral frequently accessed
directories (even between
vim sessions). Combined with current lookupfile, user can locate
file even more
effeciently.
Problems find today
- When path is very long (exceed screen width), find
directory-content-window's filelist is messed up
- Input wrong path, RETURN, find input focus is automatically move to
the line beginning. It's more desirable that the input focus remain at
line end to facilitate user correct the last path segment
- Input wrong path, RETURN, move to line end and delete the last path
segment, input correct path segment keyword, find popup-match-window
not showup
- Input wrong path, RETURN, move to line end and delete the last path
segment, input intact correct path segment (not path keyword), RETURN,
find an empty buffer opened (instead of popup
directory-content-window)
- Sometimes, the following error msg popup serveral times 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)
Error detected while processing function
<SNR>74_AcceptFile..<SNR>33_IdoAccept..lookupfile#AcceptFile:
line 15:
E121: Undefined variable: g:LookupFile_LookupNotifyFunc
My vimrc configuration is
command! WalkCur :exec "LUWalk" expand('%:p:h').'/'
nmap <unique> <silent> w :WalkCur<CR>
nmap <unique> <silent> b :LUBufs<CR>
let g:LookupFile_PreserveLastPattern=0
let g:LookupFile_AlwaysAcceptFirst=1
let g:LookupFile_FileFilter =
'\.class$\|\.o$\|\.obj$\|\.exe$\|\.jar$\|\.zip$\|\.war$\|\.tgz$\|\.ear$'
Thanks
Eddy
2006/8/14, Hari Krishna Dara <[EMAIL PROTECTED]>:
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
