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