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)
- 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 !!).
- 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
- 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)
- Ido can highlight the keyword in the matched filenames
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
2006/8/10, Hari Krishna Dara <[EMAIL PROTECTED]>:
On Wed, 9 Aug 2006 at 10:49pm, Yakov Lerner wrote:
> On 8/9/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > I am not completely clear on your question. You can always generate a
> > single tag file which includes all the directories that you would visit.
> > Normally, for development branches, this is easy as you can generate the
> > tag file right at the root of the branch, including everything under it.
> > If your usage scenario is such that the directories that you visit are
> > scattered all over the filesystem, then you should still be able to
> > create a command that will build a central tag file for all these
> > directories. The sample find command given can be extended for this
> > case, as the find manual suggests that you can have multiple "paths".
> > Create a script and have it run on demand or through a scheduler.
>
> Hari, This is certain burden that you place on the users.
> I'd prefer that you had a hotkey such that when you press it
> at the script prompt, script would automatically runs 'find'
> from the current dir to refresh the filelist.
> And if dirlist for current dir does not exist, that it
> create it automatically on the first invocation.
> Yes I am spoiled kid ....
>
> Yakov
Building filelist for large directories takes significant time
(especially on windows, as cygwin find is slow), so running the command
outside in a separate window is preferale, and the script doesn't need
to bother about platform/shell specific issues (like what if cygwin is
not installed?). The plugin is written to be independent of any external
tools, and it uses well known file format (tags) to index filenames.
How you build the index is complete independent, and there is no generic
tool to support it (like ctags). You don't need to even use find to
build this index.
Also, all my scripts that refresh tag files (and even ID database) do
the below trick:
command > tags.new
mv tags.new tags
The advantage is that while the command is taking a long time to run, I
can continue to work with the old tags file. This flexibility is lost if
your vim session is typed up while the plugin is rebuilding the file.
I don't understand the advantage of having a separate filelist for each
directory (this means, you have to change Lookupfile_TagExpr such that
it looks only into the current directory). I very often move around in
the filesytem (which is why I created PushPop.vim plugin), so the
current directory is kind of relatively insignificant. Isn't it
preferable to have a single list at the root level, though it means
building the list takes longer (but how often do you have the list
changing anyway)? What if you cd into a directory, whose one of the
parents already has the filelist built? Do you still want to build it? I
guess a usage scenario will help me understand the usefulness of this.
It will also help if someone can explain how the emacs tool behaves in
this regard. Does it use a file index and if so how does it build? If
not file indexing is involved, how does it manage to match files at
realtime? Etc.
--
Thanks,
Hari
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
