What are the easiest/best methods for managing your ctags tag file(s)?

Question

I just started using ctags and greatly appreciate the tool but the way I manage my tag file is somewhat cumbersome in my opinion and very inflexible.

How I currently manage my tag file:

1. I have one monolithic tag file stored in my home folder at ~/.vim/tags
2. When I update my code or change projects I run a script that deletes the old tag file and regenerates the monolithic tag file (you have to change the location of where ctags executes from when you change projects)

Having one monolithic tag file works for me because it lets me jump to all the relevant symbols for the current project I am working on.

Would a single monolithic tag file will not work for a large/huge codebase? Why would a huge tag file not work on a large/huge codebase?

What are other ways to manage your tag file (or tag files plural)?

And why would your new method for managing your tag files be better? (Presumably a better solution would sometimes be more complex. So if your solution is more complex I am asking you what is the added benefit for a more complex method for managing your tag files.)

---

p.s. I found a stackoverflow question talking about ctags called "vimctags-tips-and-tricks" but this question doesn't talk about how to manage your tag files.

Petrel

Answer 1

I put my tags file in the project directory. That keeps the tags separate for each project.

For large codebases, I just reduce the frequency at which I update it. I usually only update it if I try to jump to a keyword and it's not there for some reason. After all, the purpose is to quickly get to some other part of the code, and if it gets there by whatever means, then it worked even if the tag file is out of date.

Silvern

+1 on the approach. I also use cscope - and have a three-liner shell script that recreates the files for both when they become stale. – Xylo

Answer 2

One approach I've recently become fond of is using VCS (Version Control Systems) hooks to generate the ctags files. I use git locally even for small projects and such, and so the ctags gets updated every time I commit (this is, obviously, possible with all other VCS's out there).

I personally like to place the ctags file in each project's directory, but this approach should work just as well globally.

EDIT: VCS hooks are scripts or programs that run automatically when certain actions are performed, such as checkout, commit, revert and others.
For further reading I suggest the following links:

• Subversion: The Implementing Repository Hooks and Repository Hooks sections of the SVN book.
• Git: The Git Hooks section of the Git Community Book.
• Mercurial: The Handling repository events with hooks section from the online book Mercurial: The Definitive Guide.

Hooks are generally available in all VCS's I've bumped into, and I'm sure you'll be able to find documentation for the one you chose to use.

Bibbs

I don't know what "VCS hooks" are. Maybe you could elaborate a little more on VCS hooks and how it knows to regen tags upon committing? – Petrel

I've updated the answer and hope it provides more information now. I'll be happy to further clarify if necessary. – Bibbs

client side or server side hooks? I'd think client side is better for what you want to do, but Subversion doesn't do client-side. – Goodsized

Answer 3

Much like Greg, I keep the tag file in the project directory. I then use project plugin with it's in= tag to set up the tag file location and whether to use recursion when regenerating tags and cscope.out for different projects.

I usually only update the tags file when there have been significant changes as the tag will usually get you to the right line (or at least nearly the right line) even if it's out of date. The main reason I update is if I've added a new enum, struct or similar and I want the tag syntax highlighting to be updated.

Crossquestion

Answer 4

Except for vim plugins for which I have only one tags file, I also have one ctags database per project.

This implies two things:

1. a way to detect "projects" and to set a vim setting accordingly. There are plenty plugins able to do that.
2. a way to have different settings for different projects simultaneously. That's where setlocal tags=... (/setlocal tags+=) plays it's part.

Most of the times projects don't share tags. As a consequence, I'm happy with detecting the current project to define automatically where I update the tags, and where I read them. These are two distinct use cases, and vim only handles (natively) the last one. Plugins that handle the first use case need to specify a (buffer local) variable to store the information.

Actually while saving a file should update only one specific tags database, we may have to fetch tags for several bases at once. This is a use case I have when I'm working on libraries/projects that depends on each other: I often need to check something in the (~3rd party) code I import. I could have used a global &tags options, but I've chosen (for now) to have distinct values in distinct buffers. Once again, this use case is taken care of thanks to the local-vimrc plugin I'm using.

Regarding updating the tags database, it's done in a plugin (that I'm maintaining, but there exist others with similar capabilities): I remove the tags associated to the current file from the associated project tags database, then I update with the -a option, in the background. There is really no need to parse the complete project every time we save a file.

In the case project files are updated outside vim scope, I still have the possibility to run tags on the entire project. While everything is transparent with commit hooks, I'm able to update vim spell checking dictionary in order to to not flag code identifiers as misspelled words. I suspect it would be a little bit more tedious with pure a commit-hook approach.

Pym