1.. _ctags-faq(7): 2 3============================================================== 4ctags-faq 5============================================================== 6 7Universal Ctags FAQ 8 9:Version: 5.9.0 10:Manual group: Universal Ctags 11:Manual section: 7 12 13This is the Universal Ctags FAQ (Frequently-Asked Questions). 14It is based on `Exuberant Ctags FAQ <http://ctags.sourceforge.net/faq.html>`_ 15 16.. contents:: 17 18DESCRIPTION 19----------- 20 21.. TODO: https://github.com/universal-ctags/ctags/issues/2312 22 #1421: feature: clean up stale tags when appending (`-a`) 23 #2356: can't pre-process the macro but it works with Exuberant Ctags 5.8 24 #2540: C/C++：conditional compilation like #ifdef will cause parse errror 25 26What is the difference between Universal Ctags and Exuberant Ctags? 27~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 28 29Universal Ctags is an unofficial fork of Exuberant Ctags. 30The differences are summarized in :ref:`ctags-incompatibilities(7) <ctags-incompatibilities(7)>` man page. 31 32The most notable one is that Universal Ctags doesn't read ``~/.ctags`` file. 33Instead, it reads ``*.ctags`` under ``~/.ctags.d`` directory. 34 35How can I avoid having to specify my favorite option every time? 36~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 38Either by setting the environment variable ``CTAGS`` to your custom 39options, or putting them into a ``~/.ctags.d/anyname.ctags`` file in your home 40directory. 41 42What are these strange bits of text beginning with ``;"`` which follow many of the lines in the tag file? 43~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 44 45These are *extension flags*. They are added in order to provide extra 46information about the tag that may be utilized by the editor in order to 47more intelligently handle tags. They are appended to the EX command part of 48the tag line in a manner that provides backwards compatibility with existing 49implementations of the Vi editor. The semicolon is an EX command separator 50and the double quote begins an EX comment. Thus, the extension flags appear 51as an EX comment and should be ignored by the editor when it processes the 52EX command. 53 54Some non-vi editors, however, implement only the bare minimum of EX commands 55in order to process the search command or line number in the third field of 56the tag file. If you encounter this problem, use the option ``--format=1`` to 57generate a tag file without these extensions (remember that you can set the 58CTAGS environment variable to any default arguments you wish to supply). Then 59ask the supplier of your editor to implement handling of this feature of EX 60commands. 61 62Why can't I jump to ``class::member``? 63~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64 65Because, by default, ctags only generates tags for the separate identifiers 66found in the source files. If you specify the ``--extra=+q`` option, then 67ctags will also generate a second, class-qualified tag for each class member 68(data and function/method) in the form ``class::member`` for C++, and in the form 69``class.method`` for Eiffel and Java. 70 71Why do I end up on the wrong line when I jump to a tag? 72~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 73 74By default, ctags encodes the line number in the file where macro (``#define``) 75tags are found. This was done to remain compatible with the original UNIX 76version of ctags. If you change the file containing the tag without 77rebuilding the tag file, the location of tag in the tag file may no longer 78match the current location. 79 80In order to avoid this problem, you can specify the option ``--excmd=p``, 81which causes ctags to use a search pattern to locate macro tags. I have 82never uncovered the reason why the original UNIX ctags used line numbers 83exclusively for macro tags, but have so far resisted changing the default 84behavior of Exuberant (and Universal) Ctags to behave differently. 85 86How do I jump to the tag I want instead of the wrong one by the same name? 87~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 88 89A tag file is simple a list of tag names and where to find them. If there 90are duplicate entries, you often end up going to the wrong one because the 91tag file is sorted and your editor locates the first one in the tag file. 92 93Standard Vi provides no facilities to alter this behavior. However, Vim 94has some nice features to minimize this problem, primarily by examining all 95matches and choosing the best one under the circumstances. Vim also provides 96commands which allow for selection of the desired matching tag. 97 98How can I locate all references to a specific function or variable? 99~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 100 101There are several packages already available which provide this capability. 102Namely, these are: GLOBAL source code tag system, GNU id-utils, cscope, 103and cflow. As of this writing, they can be found in the following locations: 104 105- GLOBAL: http://www.gnu.org/software/global 106- id-utils: http://www.gnu.org/software/idutils/idutils.html 107- cscope: http://cscope.sourceforge.net 108- cflow: ftp://www.ibiblio.org/pub/Linux/devel/lang/c 109 110Why does appending tags to a tag file tag so long? 111~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 112 113Sometimes, in an attempt to build a global tag file for all source files in 114a large source tree of many directories, someone will make an attempt to run 115ctags in append (``-a``) mode on every directory in the hierarchy. Each time 116ctags is invoked, its default behavior is to sort the tag file once the tags 117for that execution have been added. As the cumulative tag file grows, the sort 118time increases arithmetically. 119 120The best way to avoid this problem (and the most efficient) is to make 121use of the ``--recurse`` (or ``-R``) option of ctags by executing the following 122command in the root of the directory hierarchy (thus running ctags only once): 123 124 .. code-block:: sh 125 126 ctags -R 127 128If you really insist on running ctags separately on each directory, you can 129avoid the sort pass each time by specifying the option ``--sort=no``. Once the 130tag file is completely built, use the sort command to manually sort the 131final tag file, or let the final invocation of ctags sort the file. 132 133How should I set up tag files for a multi-level directory hierarchy? 134~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 135 136There are a few ways of approaching this: 137 1381. A local tag file in each directory containing only the tags for source 139 files in that directory. 140 1412. One single big, global tag file present in the root directory of your 142 hierarchy, containing all tags present in all source files in the 143 hierarchy. 144 1453. A local tag file in each directory containing only the tags for source 146 files in that directory, in addition to one single global tag file 147 present in the root directory of your hierarchy, containing all 148 non-static tags present in all source files in the hierarchy. 149 1504. A local tag file in each directory of the hierarchy, each one 151 containing all tags present in source files in that directory and all 152 non-static tags in every directory below it (note that this implies 153 also having one big tag file in the root directory of the hierarchy). 154 155Each of these approaches has its own set of advantages and disadvantages, 156depending upon your particular conditions. Which approach is deemed best 157depends upon the following factors: 158 159A. The ability of your editor to use multiple tag files. 160 161 If your editor cannot make use of multiple tag files (original vi 162 implementations could not), then one large tag file is the only way to 163 go if you ever desire to jump to tags located in other directories. If 164 you never need to jump to tags in another directory (i.e. the source 165 in each directory is entirely self-contained), then a local tag file 166 in each directory will fit your needs. 167 168B. The time is takes for your editor to look up a tag in the tag file. 169 170 The significance of this factor depends upon the size of your source 171 tree and on whether the source files are located on a local or remote 172 file system. For source and tag files located on a local file system, 173 looking up a tag is not as big a hit as one might first imagine, since 174 vi implementations typically perform a binary search on a sorted tag 175 file. This may or may not be true for the editor you use. For files 176 located on a remote file system, reading a large file is an expensive 177 operation. 178 179C. Whether or not you expect the source code to change and the time it 180 takes to rebuild a tag file to account for changes to the source code. 181 182 While Universal Ctags is particularly fast in scanning source code 183 (around 1-2 MB/sec), a large project may still result in objectionable 184 delays if one wishes to keep their tag file(s) up to date on a 185 frequent basis, or if the files are located on a remote file system. 186 187D. The presence of duplicate tags in the source code and the ability to 188 handle them. 189 190 The impact of this factor is influenced by the following three issues: 191 192 1. How common are duplicate tags in your project? 193 194 2. Does your editor provide any facilities for dealing with duplicate 195 tags? 196 197 While standard vi does not, many modern vi implementations, such 198 as Vim have good facilities for selecting the desired match from 199 the list of duplicates. If your editor does not support duplicate 200 tags, then it will typically send you to only one of them, whether 201 or not that is the one you wanted (and not even notifying you that 202 there are other potential matches). 203 204 3. What is the significance of duplicate tags? 205 206 For example, if you have two tags of the same name from entirely 207 isolated software components, jumping first to the match found 208 in component B while working in component A may be entirely 209 misleading, distracting or inconvenient (to keep having to choose 210 which one if your editor provides you with a list of matches). 211 However, if you have two tags of the same name for parallel builds 212 (say two initialization routines for different hosts), you may 213 always want to specify which one you want. 214 215Of the approaches listed above, I tend to favor Approach 3. My editor of 216choice is Vim, which provides a rich set of features for handling multiple 217tag files, which partly influences my choice. If you are working with 218source files on a remote file system, then I would recommend either 219Approach 3 or Approach 4, depending upon the hit when reading the global 220tag file. 221 222The advantages of Approach 3 are many (assuming that your editor has 223the ability to support both multiple tag files and duplicate tags). All 224lookups of tag located in the current directory are fast and the local 225tag file can be quickly and easily regenerated in one second or less 226(I have even mapped a keystroke to do this easily). A lookup of a 227(necessarily non-static) tag found in another directory fails a lookup in 228the local tag file, but is found in the global tag file, which satisfies 229all cross-directory lookups. The global tag file can be automatically 230regenerated periodically with a cron job (and perhaps the local tag files 231also). 232 233Now I give an example of how you would implement Approach 3. Means of 234implementing the other approaches can be performed in a similar manner. 235 236Here is a visual representation of an example directory hierarchy: 237 238:: 239 240 project 241 `-----misccomp 242 | `... 243 `-----sysint 244 `-----client 245 | `-----hdrs 246 | `-----lib 247 | `-----src 248 | `-----test 249 `-----common 250 | `-----hdrs 251 | `-----lib 252 | `-----src 253 | `-----test 254 `-----server 255 `-----hdrs 256 `-----lib 257 `-----src 258 `-----test 259 260Here is a recommended solution (conceptually) to build the tag files: 261 2621. Within each of the leaf nodes (i.e. ``hdrs``, ``lib``, ``src``, ``test``) build a tag 263 file using "``ctags *.[ch]``". This can be easily be done for the whole 264 hierarchy by making a shell script, call it ``dirtags``, containing the 265 following lines: 266 267 .. code-block:: sh 268 269 #!/bin/sh 270 cd $1 271 ctags * 272 273 Now execute the following command: 274 275 .. code-block:: sh 276 277 find * -type d -exec dirtags {} \; 278 279 These tag files are trivial (and extremely quick) to rebuild while 280 making changes within a directory. The following Vim key mapping is 281 quite useful to rebuild the tag file in the directory of the current 282 source file: 283 284 .. code-block:: text 285 286 :nmap ,t :!(cd %:p:h;ctags *.[ch])&<CR><CR> 287 2882. Build the global tag file: 289 290 .. code-block:: sh 291 292 cd ~/project 293 ctags --file-scope=no -R 294 295 thus constructing a tag file containing only non-static tags for all 296 source files in all descendent directories. 297 2983. Configure your editor to read the local tag file first, then consult 299 the global tag file when not found in the local tag file. In Vim, 300 this is done as follows: 301 302 .. code-block:: text 303 304 :set tags=./tags,tags,~/project/tags 305 306If you wish to implement Approach 4, you would need to replace the 307``dirtags`` script of step 1 with the following: 308 309 .. code-block:: sh 310 311 #!/bin/sh 312 cd $1 313 ctags * 314 # Now append the non-static tags from descendent directories 315 find * -type d -prune -print | ctags -aR --file-scope=no -L- 316 317And replace the configuration of step 3 with this: 318 319 .. code-block:: text 320 321 :set tags=./tags;$HOME,tags 322 323As a caveat, it should be noted that step 2 builds a global tag file whose 324file names will be relative to the directory in which the global tag file 325is being built. This takes advantage of the Vim ``tagrelative`` option, 326which causes the path to be interpreted a relative to the location of the 327tag file instead of the current directory. For standard vi, which always 328interprets the paths as relative to the current directory, we need to 329build the global tag file with absolute path names. This can be 330accomplished by replacing step 2 with the following: 331 332 .. code-block:: sh 333 334 cd ~/project 335 ctags --file-scope=no -R `pwd` 336 337Does Universal Ctags support Unicode file names? 338~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 339 340.. MEMO: from https://github.com/universal-ctags/ctags/issues/1837 341 342Yes, Unicode file names are supported on unix-like platforms (Linux, macOS, 343Cygwin, etc.). 344 345However, on Windows, you need to use Windows 10 version 1903 or later to use 346Unicode file names. (This is an experimental feature, though.) On older versions 347on Windows, Universal Ctags only support file names represented in the current 348code page. If you still want to use Unicode file names on them, use Cygwin or 349MSYS2 version of Universal Ctags as a workaround. 350 351Why does zsh cause "zsh: no matches found" error? 352~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 353 354.. MEMO: from https://github.com/universal-ctags/ctags/issues/2842 355 356zsh causes error on the following cases; 357 358 .. code-block:: sh 359 360 ctags --extra=+* ... 361 ctags --exclude=foo/* ... 362 363This is the 2nd most significant incompatibility *feature* of zsh. 364 365Cited from "Z-Shell Frequently-Asked Questions", "`2.1: Differences from sh and 366ksh <http://zsh.sourceforge.net/FAQ/zshfaq02.html>`_"; 367 368 ... The next most classic difference is that unmatched glob patterns cause 369 the command to abort; set ``NO_NOMATCH`` for those. 370 371You may add "``setopt nonomatch``" on your ``~/.zshrc``. Or you can escape glob 372patterns with backslash; 373 374 .. code-block:: sh 375 376 ctags --extra=+\* ... 377 ctags --exclude=foo/\* ... 378 379Or quote them; 380 381 .. code-block:: sh 382 383 ctags '--extra=+*' ... 384 ctags '--exclude=foo/*' ... 385 386SEE ALSO 387-------- 388 389The official Universal Ctags web site at: 390 391https://ctags.io/ 392 393:ref:`ctags(1) <ctags(1)>`, :ref:`tags(5) <tags(5)>` 394 395AUTHOR 396------ 397 398This FAQ is based on `Exuberant Ctags FAQ <http://ctags.sourceforge.net/faq.html>`_ by 399Darren Hiebert and vberthoux@users.sourceforge.net 400 401Universal Ctags project: https://ctags.io/ 402