work with vim-rooter plugin together is great.

[stardiviner]

Here is the it. https://github.com/airblade/vim-rooter/issues/13

[stardiviner]

I guess maybe let easytags build tags file under current directory instead of file's current directory. For example, I open a file plugin/neocomplcache.vim, then the result of :pwd will be in plugin/, I hope easytags will building tags in this -> (I execute :Rooter to go to root of repo, or :cd .. to root) directory.

[stardiviner]

I know an option autochdir, but I need it.

[smackesey]

@NagatoPain I don't quite understand your request, since Rooter sets the CWD and therefore the location that easytags will write to (if tags=./tags and g:easytags_dynamic_files=1).

[albertnetymk]

I think this behavior (having project specific tags) make more sense. Maybe it's better to make it default? (g:easytags_dynamic_files does the trick, but it's not the default behavior.) Do you use this plugin with vim-rooter?

[xolox]

@albertnetymk: As you said g:easytags_dynamic_files does the trick, and it's clearly documented so should be fairly easy to find. I'm not going to change the plug-in's default behavior because g:easytags_dynamic_files is only one of several use cases. For me personally it's a minority use case; I never actually use g:easytags_dynamic_files, the only reason I added it is because several users requested it.

[albertnetymk]

@xolox Thank you for adding this feature, even though you don't use it. Out of curiosity, what's your use case? According to my experiment with this plugin, the default use case is to have one global tag files, and all tag info is stored in it. Isn't this too inefficient? Is it possible that there's name conflicts? (Same type structure in different projects).

[xolox]

Thank you for adding this feature, even though you don't use it. Out of curiosity, what's your use case?

The vim-easytags is most useful to me for big projects, but since I created the plug-in and started using it I've become accustomed to having it available for all files on my system, and I wouldn't want to do without that now. I use file type specific tags files instead of a single, global tags file. I added support for those after I noticed that a global tags file wasn't working out very well once it grew beyond a couple of megabytes :-).

According to my experiment with this plugin, the default use case is to have one global tag files, and all tag info is stored in it. Isn't this too inefficient?

Once the plug-in is used for a while the global tags file becomes very inefficient indeed (once it grows beyond a certain size, I'd say a couple of megabytes, but it depends on disk speed and other factors of the target system).

Is it possible that there's name conflicts? (Same type structure in different projects).

This is true however I don't consider it to be a serious problem:

• When you jump to a duplicate tag with Ctrl-], Vim will ask to which of the duplicate tags you want to jump
• In the case of dynamic syntax highlighting there's no conflict; the tag will be highlighted just fine

---

Sometimes I doubt whether it's wise for the vim-easytags plug-in to have so many options (and corresponding modes of operation) however in the years since I published the first version I certainly learned that there are more use cases to the vim-easytags plug-in then I could have ever imagined possible :smiley:

[albertnetymk]

Thank you for sharing the story. (You could add this to README so that others could get this info easily.) File specific tag file just delays the occurrence of efficiency problems to some extent, and I still would prefer to use the project specific tag files for projects. If you use fugitive, the tags option is handled as well.

To each his own. Thank you for this helpful plugin.