我刚刚开始使用 ctags，并且非常欣赏这个工具，但我认为管理标签文件的方式有点麻烦而且非常不灵活。
我目前如何管理我的标签文件：
- 我的主文件夹中存储了一个整体标签文件
~/.vim/tags
- 当我更新我的代码或更改我运行的项目时一个删除旧标签文件并重新生成整体标签文件的脚本（当您更改项目时，您必须更改 ctags 的执行位置）
拥有一个整体标签文件对我来说很有效，因为它可以让我跳转到所有相关的符号我目前正在进行的项目。
单个整体标签文件不适用于大型/巨大的代码库吗？ 为什么一个巨大的标签文件不能在大型/巨大的代码库上工作？
还有哪些其他方法来管理您的标签文件（或复数标签文件）？
为什么您的新标签文件不能 在大型代码库上工作？管理标签文件的方法更好吗？（大概更好的解决方案有时会更复杂。因此，如果您的解决方案更复杂，我想问您管理标签文件的更复杂方法的额外好处是什么.)
ps 我发现了一个关于 ctags 的 stackoverflow 问题，名为“vimctags-tips-and-tricks ”但是这个问题并没有讨论如何管理你的标签文件。
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:
- I have one monolithic tag file stored in my home folder at
~/.vim/tags
- 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.
发布评论
评论（4）
我最近喜欢的一种方法是使用 VCS（版本控制系统）挂钩来生成 ctags 文件。 即使对于小型项目等，我也会在本地使用 git，因此每次提交时 ctags 都会更新（显然，这对于所有其他 VCS 都是可能的）。
我个人喜欢将 ctags 文件放在每个项目的目录中，但这种方法应该在全球范围内都有效。
编辑：VCS 挂钩是在执行某些操作（例如签出、提交、恢复等）时自动运行的脚本或程序。
为了进一步阅读，我建议使用以下链接：
Hooks 通常在我遇到过的所有 VCS 中都可用，我相信您能够找到您选择使用的版本的文档。
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:
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.
除了我只有一个标签文件的 vim 插件之外，每个项目还有一个 ctags 数据库。
这意味着两件事：
setlocaltags=...(/setlocaltags+=) 发挥作用的地方。大多数时候项目不共享标签。 因此，我很高兴检测当前项目以自动定义更新标签的位置以及读取标签的位置。 这是两个不同的用例，vim 仅处理（本机）最后一个用例。 处理第一个用例的插件需要指定一个（缓冲区本地）变量来存储信息。
实际上，在保存文件时应该只更新一个特定的标签数据库，我们可能必须一次获取多个碱基的标签。 这是我在处理相互依赖的库/项目时遇到的一个用例：我经常需要检查我导入的（~第 3 方）代码中的某些内容。 我本可以使用全局
&tags选项，但我（目前）选择在不同的缓冲区中拥有不同的值。 再次感谢我正在使用的 local-vimrc 插件，这个用例得到了处理。关于更新标签数据库，它是在 插件 中完成的（我正在维护，但有存在其他具有类似功能的标签）：我从关联的项目标签数据库中删除与当前文件关联的标签，然后在后台使用
-a选项进行更新。 实际上没有必要每次保存文件时都解析整个项目。如果项目文件在 vim 范围之外更新，我仍然可以在整个项目上运行标签。 虽然提交挂钩的一切都是透明的，但我可以更新 vim 拼写检查字典，以便不将代码标识符标记为拼写错误的单词。 我怀疑使用纯粹的提交挂钩方法会有点乏味。
Except for vim plugins for which I have only one tags file, I also have one ctags database per project.
This implies two things:
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
&tagsoptions, 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
-aoption, 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.
我将我的
tags文件放在项目目录中。 这使得每个项目的标签都是分开的。对于大型代码库，我只是降低更新频率。 我通常只在我尝试跳转到某个关键字但由于某种原因不存在时才更新它。 毕竟，目的是快速到达代码的其他部分，并且如果通过任何方式到达那里，那么即使标记文件已过期，它也可以工作。
I put my
tagsfile 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.
就像 Greg 一样，我将标记文件保存在项目目录中。 然后我使用 project 插件及其
in= 标签设置标签文件位置以及为不同项目重新生成tags和cscope.out时是否使用递归。我通常只在发生重大更改时更新标签文件，因为标签通常会让您到达正确的行（或至少接近正确的行），即使它已经过时。 我更新的主要原因是，如果我添加了新的枚举、结构或类似的内容，并且我想要 标签语法突出显示已更新。
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 regeneratingtagsandcscope.outfor 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.