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
