CTAGS-FAQ(7)

📦
version 6.2.1 · 6 versions
, in alpine 3.24, fedora 43, fedora 44

💖 CTAGS-FAQ(7) 💖

okay bestie, welcome to the Universal Ctags FAQ page — aka ctags-faq, the group chat where all your ctags questions get answered. This is literally the Universal Ctags FAQ (Frequently-Asked-Questions), and it's based on the Exuberant Ctags FAQ at <http://ctags.sourceforge.net/faq.html>. 🦋

📋 Contents

  • DESCRIPTION
    • What is the difference between Universal Ctags and Exuberant Ctags?
    • How can I avoid having to specify my favorite option every time?
    • What are these strange bits of text beginning with ;" which follow many of the lines in the tag file?
    • Why can't I jump to class::member?
    • Why do I end up on the wrong line when I jump to a tag?
    • How do I jump to the tag I want instead of the wrong one by the same name?
    • How can I locate all references to a specific function or variable?
    • Why does appending tags to a tag file tag so long?
    • How should I set up tag files for a multi-level directory hierarchy?
    • Does Universal Ctags support Unicode file names?
    • Why does zsh cause "zsh: no matches found" error?
  • SEE ALSO
  • AUTHOR

✨ DESCRIPTION ✨

💅 What is the difference between Universal Ctags and Exuberant Ctags?

So the tea is: Universal Ctags is an unofficial fork of Exuberant Ctags. All the differences get summarized in the ctags-incompatibilities(7) man page, so go read that if you want the full lore.

The most notable difference — the one that's giving main character energy — is that Universal Ctags does not read the ~/.ctags file. Instead, it reads *.ctags files under the ~/.ctags.d directory. slay, different directory, different rules. 💅

🌸 How can I avoid having to specify my favorite option every time?

Two ways, bestie, pick your fighter:

  • Set the environment variable CTAGS to your custom options, or
  • Put them into a ~/.ctags.d/anyname.ctags file in your home directory.

That's it. Never type that option again. ✨

🔥 What are these strange bits of text beginning with ;" which follow many of the lines in the tag file?

okay so those are extension flags. They get added to give extra info about the tag that your editor can use to handle tags more intelligently. They're appended to the EX command part of the tag line in a way that stays backwards compatible with existing implementations of the Vi editor. The semicolon is an EX command separator, and the double quote begins an EX comment. So basically the extension flags show up as an EX comment, and the editor should just ignore them when it processes the EX command. 🙈

BUT. Some non-vi editors only implement the bare minimum of EX commands — just enough to process the search command or the line number in the third field of the tag file. If you hit that problem, use the option --format=1 to generate a tag file without these extensions (and remember, you can set the CTAGS environment variable to any default arguments you wish to supply 🫶). Then go ask the supplier of your editor to actually implement handling of this feature of EX commands. periodt.

💀 Why can't I jump to class::member?

Because by default, ctags only generates tags for the separate identifiers found in the source files. That's the whole reason, no cap.

If you specify the --extra=+q option, then ctags will also generate a second, class-qualified tag for each class member (data and function/method) in the form class::member for C++, and in the form class.method for Eiffel and Java. iconic. 👑

😭 Why do I end up on the wrong line when I jump to a tag?

By default, ctags encodes the line number in the file where macro (#define) tags are found. This was done to stay compatible with the original UNIX version of ctags. But here's the catch: if you change the file containing the tag without rebuilding the tag file, the location of the tag in the tag file may no longer match the current location. so you jump… somewhere. wrong place. tragic. 💀

To dodge this whole problem, you can specify the option --excmd=p, which makes ctags use a search pattern to locate macro tags. And listen — the original author literally says: "I have never uncovered the reason why the original UNIX ctags used line numbers exclusively for macro tags, but have so far resisted changing the default behavior of Exuberant (and Universal) Ctags to behave differently." so yeah. it's giving legacy. we live with it. 🫶

🦋 How do I jump to the tag I want instead of the wrong one by the same name?

A tag file is simple — literally just a list of tag names and where to find them. If there are duplicate entries, you often end up going to the wrong one, because the tag file is sorted and your editor locates the first one in the tag file. vibe check: failed. 😭

Standard Vi provides no facilities to alter this behavior. However, Vim has some nice features to minimize this problem, primarily by examining all matches and choosing the best one under the circumstances. Vim also provides commands which allow for selection of the desired matching tag. Vim girlies stay winning. ✨

🎀 How can I locate all references to a specific function or variable?

There are several packages already available which provide this capability. Namely, these are: GLOBAL source code tag system, GNU id-utils, cscope, and cflow. As of this writing, they can be found in the following locations:

go forth and grep the vibes. 🌈

🌸 Why does appending tags to a tag file tag so long?

Sometimes, in an attempt to build a global tag file for all source files in a large source tree of many directories, someone will make an attempt to run ctags in append (-a) mode on every directory in the hierarchy. And here's the problem: each time ctags is invoked, its default behavior is to sort the tag file once the tags for that execution have been added. As the cumulative tag file grows, the sort time increases arithmetically. so it just keeps getting slower. not the slay we wanted. 😭

The best way to avoid this problem (and the most efficient) is to make use of the --recurse (or -R) option of ctags by executing the following command in the root of the directory hierarchy (thus running ctags only once):

ctags -R

If you really, really insist on running ctags separately on each directory, you can avoid the sort pass each time by specifying the option --sort=no. Once the tag file is completely built, use the sort command to manually sort the final tag file, or let the final invocation of ctags sort the file. you got this. 💪

👑 How should I set up tag files for a multi-level directory hierarchy?

There are a few ways of approaching this:

  1. A local tag file in each directory containing only the tags for source files in that directory.
  2. One single big, global tag file present in the root directory of your hierarchy, containing all tags present in all source files in the hierarchy.
  3. A local tag file in each directory containing only the tags for source files in that directory, in addition to one single global tag file present in the root directory of your hierarchy, containing all non-static tags present in all source files in the hierarchy.
  4. A local tag file in each directory of the hierarchy, each one containing all tags present in source files in that directory and all non-static tags in every directory below it (note that this implies also having one big tag file in the root directory of the hierarchy).

Each of these approaches has its own set of advantages and disadvantages, depending upon your particular conditions. Which approach is deemed best depends upon the following factors:

A. The ability of your editor to use multiple tag files.

If your editor cannot make use of multiple tag files (original vi implementations could not), then one large tag file is the only way to go if you ever desire to jump to tags located in other directories. If you never need to jump to tags in another directory (i.e. the source in each directory is entirely self-contained), then a local tag file in each directory will fit your needs.

B. The time is takes for your editor to look up a tag in the tag file.

The significance of this factor depends upon the size of your source tree and on whether the source files are located on a local or remote file system. For source and tag files located on a local file system, looking up a tag is not as big a hit as one might first imagine, since vi implementations typically perform a binary search on a sorted tag file. This may or may not be true for the editor you use. For files located on a remote file system, reading a large file is an expensive operation. 💸

C. Whether or not you expect the source code to change and the time it takes to rebuild a tag file to account for changes to the source code.

While Universal Ctags is particularly fast in scanning source code (around 1-2 MB/sec), a large project may still result in objectionable delays if one wishes to keep their tag file(s) up to date on a frequent basis, or if the files are located on a remote file system.

D. The presence of duplicate tags in the source code and the ability to handle them.

The impact of this factor is influenced by the following three issues:

  1. How common are duplicate tags in your project?
  2. Does your editor provide any facilities for dealing with duplicate tags?

While standard vi does not, many modern vi implementations, such as Vim have good facilities for selecting the desired match from the list of duplicates. If your editor does not support duplicate tags, then it will typically send you to only one of them, whether or not that is the one you wanted (and not even notifying you that there are other potential matches). rude. 😭

  1. What is the significance of duplicate tags?

For example, if you have two tags of the same name from entirely isolated software components, jumping first to the match found in component B while working in component A may be entirely misleading, distracting or inconvenient (to keep having to choose which one if your editor provides you with a list of matches). However, if you have two tags of the same name for parallel builds (say two initialization routines for different hosts), you may always want to specify which one you want.

Of the approaches listed above, I tend to favor Approach 3. My editor of choice is Vim, which provides a rich set of features for handling multiple tag files, which partly influences my choice. If you are working with source files on a remote file system, then I would recommend either Approach 3 or Approach 4, depending upon the hit when reading the global tag file. 🫶

The way that Approach 3 just hits different ✨ — the advantages are many, and that's assuming your editor can handle both multiple tag files and duplicate tags 💅. All your lookups of tags living in the current directory are fast, and the local tag file can be regenerated quickly and easily in one second or less (bestie literally mapped a keystroke to do it, it's that easy 😌). A lookup of a (necessarily non-static) tag found in another directory fails in the local tag file, but then it's found in the global tag file — which satisfies all cross-directory lookups 🦋. And the global tag file can be automatically regenerated periodically with a cron job (and, like, maybe the local tag files too, no biggie).

🎀 an example, because we're visual learners

okay so here's how you'd actually implement Approach 3. You can do the other approaches in a similar manner, iykyk.

Here's a visual representation of an example directory hierarchy:

project
`-----misccomp
|       `...
`-----sysint
        `-----client
        |       `-----hdrs
        |       `-----lib
        |       `-----src
        |       `-----test
        `-----common
        |       `-----hdrs
        |       `-----lib
        |       `-----src
        |       `-----test
        `-----server
                `-----hdrs
                `-----lib
                `-----src
                `-----test

And here's a recommended solution (conceptually) to build the tag files:

  1. Within each of the leaf nodes (i.e. hdrs, lib, src, test) build a tag file using "ctags *.[ch]". This can be easily be done for the whole hierarchy by making a shell script, call it dirtags, containing the following lines:
#!/bin/sh
cd $1
ctags *

Now execute the following command:

find * -type d -exec dirtags {} \;

These tag files are trivial (and extremely quick) to rebuild while making changes within a directory. The following Vim key mapping is quite useful to rebuild the tag file in the directory of the current source file:

:nmap ,t :!(cd %:p:h;ctags *.[ch])&<CR><CR>
  1. Build the global tag file:
cd ~/project
ctags --file-scope=no -R

thus constructing a tag file containing only non-static tags for all source files in all descendent directories. periodt.

  1. Configure your editor to read the local tag file first, then consult the global tag file when not found in the local tag file. In Vim, this is done as follows:
:set tags=./tags,tags,~/project/tags

If you wish to implement Approach 4, you would need to replace the dirtags script of step 1 with the following:

#!/bin/sh
cd $1
ctags *
# Now append the non-static tags from descendent directories
find * -type d -prune -print | ctags -aR --file-scope=no -L-

And replace the configuration of step 3 with this:

:set tags=./tags;$HOME,tags
⚠️ As a caveat, it should be noted that step 2 builds a global tag file whose file names will be relative to the directory in which the global tag file is being built. This takes advantage of the Vim tagrelative option, which causes the path to be interpreted a relative to the location of the tag file instead of the current directory. For standard vi, which always interprets the paths as relative to the current directory, we need to build the global tag file with absolute path names. This can be accomplished by replacing step 2 with the following:
cd ~/project
ctags --file-scope=no -R `pwd`

💜 Does Universal Ctags support Unicode file names?

Yes bestie, Unicode file names are supported on unix-like platforms (Linux, macOS, Cygwin, etc.) 🫶

However, on MS Windows, you need to use Windows 10 version 1903 or later to use Unicode file names. (This is an experimental feature, though — 👀 so, y'know, tread lightly.) On older versions on Windows, Universal Ctags only support file names represented in the current code page. If you still want to use Unicode file names on them, use Cygwin or MSYS2 version of Universal Ctags as a workaround 💅

🌸 Why does zsh cause "zsh: no matches found" error?

zsh causes error on the following cases;

ctags --extra=+* ...
ctags --exclude=foo/* ...

This is the 2nd most significant incompatibility feature of zsh 😭

Cited from "Z-Shell Frequently-Asked Questions", "2.1: Differences from sh and ksh" (http://zsh.sourceforge.net/FAQ/zshfaq02.html):

... The next most classic difference is that unmatched glob patterns cause the command to abort; set NO_NOMATCH for those.

You may add "setopt nonomatch" on your ~/.zshrc. Or you can escape glob patterns with backslash;

ctags --extra=+\* ...
ctags --exclude=foo/\* ...

Or quote them;

ctags '--extra=+*' ...
ctags '--exclude=foo/*' ...

✨ SEE ALSO ✨

The official Universal Ctags web site at:

<https://ctags.io/>

ctags(1), tags(5)

👑 AUTHOR 👑

This FAQ is based on Exuberant Ctags FAQ (http://ctags.sourceforge.net/faq.html) by Darren Hiebert and <vberthoux@users.sourceforge.net>

Universal Ctags project: <https://ctags.io/>

and that's a wrap, bestie 🎀 you just read the whole CTAGS-FAQ(7) page — this one's from version 6.2.1, and it's the CTAGS-FAQ(7) manual page fr fr. go forth and tag some code, you absolute icon 💖✨🦋

📦 where this page comes from