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.
--
Hari
>
> 2006/8/11, Hari Krishna Dara <[EMAIL PROTECTED]>:
> >
> > I had some trouble but I was able to try ido.el. At first, emacs that
> > came with cygwin didn't start at all, even when I had X running, so I
> > downloaded it separately from gnu.org. I installed ido.el directly under
> > lisp directory, as I don't know how to put it in a user directory. Next
> > I had trouble understanding how to invoke it. Once I figured out that I
> > need to use M-x, I was able to try it. See below for my response.
> >
> > On Thu, 10 Aug 2006 at 10:38pm, Eddy Zhao wrote:
> >
> > > Hi Hari:
> > >
> > > I detailed compared ido.el and lookupfile.vim today, below are some
> > > of the ido features that I personally think more convenient than the
> > > current
> > > lookupfile plugin:
> > >
> > > - Ido don't need user to generate & update tagfile (and don't have
things
> > > like LookupFile_MinPatLength and performance balance)
> >
> > As I explained before, the basic lookup mode is designed to be a lookup
> > in a full index. However, the plugin comes with a few other means to
> > lookup, and a generic extension mechanism to add more means. The version
> > I attached with my previous email includes a new mode which works
> > similar to ido.el.
> >
> > > - Ido can locate file by keyword (not regexp). For Example user only
need
> > > to input keyword "c" to locate file "my_cccc" from file "my_aaaa",
> > > "my_bbbb", "my_cccc" in the current directory. User don't need to
locate
> > > file by regexp everytime (though ido DO support regexp based locating,
I
> > > find myself almost never used that feature. User's file locating
pattern
> > is
> > > more keyword based, NOT regexp based !!).
> >
> > This is totally in the control of the new function that I added (see
> > below for an improved version), and I think it already behaves this way.
> > It may interpret some characters as filename-wildcards, as recognized by
> > glob(), so we might need to protect them (but there are not many of
> > them).
> >
> > > - Ido will automatically complete the filename under the current input
> > > focus while user is inputing keyword, and at the same time it will
show
> > > other candidate filename list that match the keyword. These two
features
> > > have a lot of advantages:
> > >
> > > * User can more quickly detect that the target file is already
located
> > > using the current keyword subset
> > >
> > > * User can more quickly detect that no file will be located using
the
> > > current keyword subset (and further-keyword-based-on-that-subset)
> > >
> > > * User don't need to press TAB to check the matched filenames, all
> > > happened automatically
> >
> > I think all this is covered.
> >
> > >
> > > - Ido can locate file in any directory (not only file in the current
> > > directory,
> > > user only need to prefix directory path, and directory patch could be
> > > completed by TAB)
> >
> > Covered as well.
> >
> > >
> > > - Ido can highlight the keyword in the matched filenames
> >
> > This can't be done, as I am using the Vim7 completion popup, and it
> > doesn't support highlighting. However, I worked around by wrapping the
> > pattern with asterisks (in the new function below), so it kind of works,
> > though not that easy to read.
> >
> > >
> > > The above features make ido very effecient, could lookupfile be
> > > modified to achieve the same effect? I think lookupfile is a very
> > > important plugin that could affect the whole vim community's editing
> > > effeciency. If you want to know anything more about ido's feature, pls
> > > let me know, I'll investigate and feedback. And I strongly recommend
> > > you to try ido once.
> > >
> > >
> > > Thanks for look into that
> > > Eddy
> >
> > Replace the s:LookupWalk function in the plugin/lookupfile.vim with
> > the one below and try it out. Let me know if this meets your needs. If
> > you read a bit about Vim scripting basics, you can start playing around
> > with this function to make the matches look better (e.g, if '/' should
> > be separate or as part of 'abbr'). See help on |complete-items| on how
> > the map works.
> >
> > function! s:LookupWalk(pattern)
> > " Determine the parent dir.
> > let parent = matchstr(a:pattern, '^.*/')
> > let pattern = strpart(a:pattern, len(parent))
> > let files = glob(parent.((pattern != '') ? '*'.pattern.'*' : '*'))
> > let fl = split(files, "\<NL>")
> > let entries = []
> > for f in fl
> > let word = isdirectory(f)?f."/":f
> > let fname = matchstr(f, '[^/]*$')
> > call add(entries, {
> > \ 'word': word,
> > \ 'abbr': fname,
> > \ 'menu': substitute(fname, '\V'.pattern, '*&*', ''),
> > \ 'kind': (isdirectory(f)?'/':' '),
> > \ })
> > endfor
> > return entries
> > endfunction
> >
> > --
> > Thanks,
> > Hari
> >
> >
> > __________________________________________________
> > 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
