1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />
<title>ctags-faq</title>
<style type="text/css">
/*
:Author: David Goodger (goodger@python.org)
:Id: $Id: html4css1.css 7952 2016-07-26 18:15:59Z milde $
:Copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
customize this style sheet.
*/
/* used to remove borders from tables and images */
.borderless, table.borderless td, table.borderless th {
border: 0 }
table.borderless td, table.borderless th {
/* Override padding for "table.docutils td" with "! important".
The right padding separates the table cells. */
padding: 0 0.5em 0 0 ! important }
.first {
/* Override more specific margin styles with "! important". */
margin-top: 0 ! important }
.last, .with-subtitle {
margin-bottom: 0 ! important }
.hidden {
display: none }
.subscript {
vertical-align: sub;
font-size: smaller }
.superscript {
vertical-align: super;
font-size: smaller }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dl.docutils dd {
margin-bottom: 0.5em }
object[type="image/svg+xml"], object[type="application/x-shockwave-flash"] {
overflow: hidden;
}
/* Uncomment (and remove this text!) to get bold-faced definition list terms
dl.docutils dt {
font-weight: bold }
*/
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.admonition, div.attention, div.caution, div.danger, div.error,
div.hint, div.important, div.note, div.tip, div.warning {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.admonition p.admonition-title, div.hint p.admonition-title,
div.important p.admonition-title, div.note p.admonition-title,
div.tip p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title, .code .error {
color: red ;
font-weight: bold ;
font-family: sans-serif }
/* Uncomment (and remove this text!) to get reduced vertical space in
compound paragraphs.
div.compound .compound-first, div.compound .compound-middle {
margin-bottom: 0.5em }
div.compound .compound-last, div.compound .compound-middle {
margin-top: 0.5em }
*/
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em ;
margin-right: 2em }
div.footer, div.header {
clear: both;
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin: 0 0 0.5em 1em ;
border: medium outset ;
padding: 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
margin-top: 0.4em }
h1.title {
text-align: center }
h2.subtitle {
text-align: center }
hr.docutils {
width: 75% }
img.align-left, .figure.align-left, object.align-left, table.align-left {
clear: left ;
float: left ;
margin-right: 1em }
img.align-right, .figure.align-right, object.align-right, table.align-right {
clear: right ;
float: right ;
margin-left: 1em }
img.align-center, .figure.align-center, object.align-center {
display: block;
margin-left: auto;
margin-right: auto;
}
table.align-center {
margin-left: auto;
margin-right: auto;
}
.align-left {
text-align: left }
.align-center {
clear: both ;
text-align: center }
.align-right {
text-align: right }
/* reset inner alignment in figures */
div.align-right {
text-align: inherit }
/* div.align-center * { */
/* text-align: left } */
.align-top {
vertical-align: top }
.align-middle {
vertical-align: middle }
.align-bottom {
vertical-align: bottom }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font: inherit }
pre.literal-block, pre.doctest-block, pre.math, pre.code {
margin-left: 2em ;
margin-right: 2em }
pre.code .ln { color: grey; } /* line numbers */
pre.code, code { background-color: #eeeeee }
pre.code .comment, code .comment { color: #5C6576 }
pre.code .keyword, code .keyword { color: #3B0D06; font-weight: bold }
pre.code .literal.string, code .literal.string { color: #0C5404 }
pre.code .name.builtin, code .name.builtin { color: #352B84 }
pre.code .deleted, code .deleted { background-color: #DEB0A1}
pre.code .inserted, code .inserted { background-color: #A3D289}
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.pre {
white-space: pre }
span.problematic {
color: red }
span.section-subtitle {
/* font-size relative to parent (h1..h6 element) */
font-size: 80% }
table.citation {
border-left: solid 1px gray;
margin-left: 1px }
table.docinfo {
margin: 2em 4em }
table.docutils {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.footnote {
border-left: solid 1px black;
margin-left: 1px }
table.docutils td, table.docutils th,
table.docinfo td, table.docinfo th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
table.docutils th.field-name, table.docinfo th.docinfo-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap ;
padding-left: 0 }
/* "booktabs" style (no vertical lines) */
table.docutils.booktabs {
border: 0px;
border-top: 2px solid;
border-bottom: 2px solid;
border-collapse: collapse;
}
table.docutils.booktabs * {
border: 0px;
}
table.docutils.booktabs th {
border-bottom: thin solid;
text-align: left;
}
h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
font-size: 100% }
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="ctags-faq">
<span id="ctags-faq-7"></span>
<h1 class="title">ctags-faq</h1>
<h2 class="subtitle" id="universal-ctags-faq">Universal Ctags FAQ</h2>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Version:</th>
<td>5.9.0</td></tr>
<tr class="manual-group field"><th class="docinfo-name">Manual group:</th><td class="field-body">Universal Ctags</td>
</tr>
<tr class="manual-section field"><th class="docinfo-name">Manual section:</th><td class="field-body">7</td>
</tr>
</tbody>
</table>
<p>This is the Universal Ctags FAQ (Frequently-Asked Questions).
It is based on <a class="reference external" href="http://ctags.sourceforge.net/faq.html">Exuberant Ctags FAQ</a></p>
<div class="contents topic" id="contents">
<p class="topic-title">Contents</p>
<ul class="simple">
<li><a class="reference internal" href="#description" id="id2">DESCRIPTION</a><ul>
<li><a class="reference internal" href="#what-is-the-difference-between-universal-ctags-and-exuberant-ctags" id="id3">What is the difference between Universal Ctags and Exuberant Ctags?</a></li>
<li><a class="reference internal" href="#how-can-i-avoid-having-to-specify-my-favorite-option-every-time" id="id4">How can I avoid having to specify my favorite option every time?</a></li>
<li><a class="reference internal" href="#what-are-these-strange-bits-of-text-beginning-with-which-follow-many-of-the-lines-in-the-tag-file" id="id5">What are these strange bits of text beginning with <tt class="docutils literal">;"</tt> which follow many of the lines in the tag file?</a></li>
<li><a class="reference internal" href="#why-can-t-i-jump-to-class-member" id="id6">Why can't I jump to <tt class="docutils literal"><span class="pre">class::member</span></tt>?</a></li>
<li><a class="reference internal" href="#why-do-i-end-up-on-the-wrong-line-when-i-jump-to-a-tag" id="id7">Why do I end up on the wrong line when I jump to a tag?</a></li>
<li><a class="reference internal" href="#how-do-i-jump-to-the-tag-i-want-instead-of-the-wrong-one-by-the-same-name" id="id8">How do I jump to the tag I want instead of the wrong one by the same name?</a></li>
<li><a class="reference internal" href="#how-can-i-locate-all-references-to-a-specific-function-or-variable" id="id9">How can I locate all references to a specific function or variable?</a></li>
<li><a class="reference internal" href="#why-does-appending-tags-to-a-tag-file-tag-so-long" id="id10">Why does appending tags to a tag file tag so long?</a></li>
<li><a class="reference internal" href="#how-should-i-set-up-tag-files-for-a-multi-level-directory-hierarchy" id="id11">How should I set up tag files for a multi-level directory hierarchy?</a></li>
<li><a class="reference internal" href="#does-universal-ctags-support-unicode-file-names" id="id12">Does Universal Ctags support Unicode file names?</a></li>
<li><a class="reference internal" href="#why-does-zsh-cause-zsh-no-matches-found-error" id="id13">Why does zsh cause "zsh: no matches found" error?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#see-also" id="id14">SEE ALSO</a></li>
<li><a class="reference internal" href="#author" id="id15">AUTHOR</a></li>
</ul>
</div>
<div class="section" id="description">
<h1><a class="toc-backref" href="#id2">DESCRIPTION</a></h1>
<!-- TODO: https://github.com/universal-ctags/ctags/issues/2312
#1421: feature: clean up stale tags when appending (`-a`)
#2356: can't pre-process the macro but it works with Exuberant Ctags 5.8
#2540: C/C++：conditional compilation like #ifdef will cause parse errror -->
<div class="section" id="what-is-the-difference-between-universal-ctags-and-exuberant-ctags">
<h2><a class="toc-backref" href="#id3">What is the difference between Universal Ctags and Exuberant Ctags?</a></h2>
<p>Universal Ctags is an unofficial fork of Exuberant Ctags.
The differences are summarized in ctags-incompatibilities(7) man page.</p>
<p>The most notable one is that Universal Ctags doesn't read <tt class="docutils literal"><span class="pre">~/.ctags</span></tt> file.
Instead, it reads <tt class="docutils literal">*.ctags</tt> under <tt class="docutils literal"><span class="pre">~/.ctags.d</span></tt> directory.</p>
</div>
<div class="section" id="how-can-i-avoid-having-to-specify-my-favorite-option-every-time">
<h2><a class="toc-backref" href="#id4">How can I avoid having to specify my favorite option every time?</a></h2>
<p>Either by setting the environment variable <tt class="docutils literal">CTAGS</tt> to your custom
options, or putting them into a <tt class="docutils literal"><span class="pre">~/.ctags.d/anyname.ctags</span></tt> file in your home
directory.</p>
</div>
<div class="section" id="what-are-these-strange-bits-of-text-beginning-with-which-follow-many-of-the-lines-in-the-tag-file">
<h2><a class="toc-backref" href="#id5">What are these strange bits of text beginning with <tt class="docutils literal">;"</tt> which follow many of the lines in the tag file?</a></h2>
<p>These are <em>extension flags</em>. They are added in order to provide extra
information about the tag that may be utilized by the editor in order to
more intelligently handle tags. They are appended to the EX command part of
the tag line in a manner that provides backwards compatibility with existing
implementations of the Vi editor. The semicolon is an EX command separator
and the double quote begins an EX comment. Thus, the extension flags appear
as an EX comment and should be ignored by the editor when it processes the
EX command.</p>
<p>Some non-vi editors, however, implement only the bare minimum of EX commands
in order to process the search command or line number in the third field of
the tag file. If you encounter this problem, use the option <tt class="docutils literal"><span class="pre">--format=1</span></tt> to
generate a tag file without these extensions (remember that you can set the
CTAGS environment variable to any default arguments you wish to supply). Then
ask the supplier of your editor to implement handling of this feature of EX
commands.</p>
</div>
<div class="section" id="why-can-t-i-jump-to-class-member">
<h2><a class="toc-backref" href="#id6">Why can't I jump to <tt class="docutils literal"><span class="pre">class::member</span></tt>?</a></h2>
<p>Because, by default, ctags only generates tags for the separate identifiers
found in the source files. If you specify the <tt class="docutils literal"><span class="pre">--extra=+q</span></tt> option, then
ctags will also generate a second, class-qualified tag for each class member
(data and function/method) in the form <tt class="docutils literal"><span class="pre">class::member</span></tt> for C++, and in the form
<tt class="docutils literal">class.method</tt> for Eiffel and Java.</p>
</div>
<div class="section" id="why-do-i-end-up-on-the-wrong-line-when-i-jump-to-a-tag">
<h2><a class="toc-backref" href="#id7">Why do I end up on the wrong line when I jump to a tag?</a></h2>
<p>By default, ctags encodes the line number in the file where macro (<tt class="docutils literal">#define</tt>)
tags are found. This was done to remain compatible with the original UNIX
version of ctags. If you change the file containing the tag without
rebuilding the tag file, the location of tag in the tag file may no longer
match the current location.</p>
<p>In order to avoid this problem, you can specify the option <tt class="docutils literal"><span class="pre">--excmd=p</span></tt>,
which causes ctags to use a search pattern to locate macro tags. 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.</p>
</div>
<div class="section" id="how-do-i-jump-to-the-tag-i-want-instead-of-the-wrong-one-by-the-same-name">
<h2><a class="toc-backref" href="#id8">How do I jump to the tag I want instead of the wrong one by the same name?</a></h2>
<p>A tag file is simple 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.</p>
<p>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.</p>
</div>
<div class="section" id="how-can-i-locate-all-references-to-a-specific-function-or-variable">
<h2><a class="toc-backref" href="#id9">How can I locate all references to a specific function or variable?</a></h2>
<p>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:</p>
<ul class="simple">
<li>GLOBAL: <a class="reference external" href="http://www.gnu.org/software/global">http://www.gnu.org/software/global</a></li>
<li>id-utils: <a class="reference external" href="http://www.gnu.org/software/idutils/idutils.html">http://www.gnu.org/software/idutils/idutils.html</a></li>
<li>cscope: <a class="reference external" href="http://cscope.sourceforge.net">http://cscope.sourceforge.net</a></li>
<li>cflow: <a class="reference external" href="ftp://www.ibiblio.org/pub/Linux/devel/lang/c">ftp://www.ibiblio.org/pub/Linux/devel/lang/c</a></li>
</ul>
</div>
<div class="section" id="why-does-appending-tags-to-a-tag-file-tag-so-long">
<h2><a class="toc-backref" href="#id10">Why does appending tags to a tag file tag so long?</a></h2>
<p>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 (<tt class="docutils literal"><span class="pre">-a</span></tt>) mode on every directory in the hierarchy. 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.</p>
<p>The best way to avoid this problem (and the most efficient) is to make
use of the <tt class="docutils literal"><span class="pre">--recurse</span></tt> (or <tt class="docutils literal"><span class="pre">-R</span></tt>) option of ctags by executing the following
command in the root of the directory hierarchy (thus running ctags only once):</p>
<blockquote>
<pre class="code sh literal-block">
ctags -R
</pre>
</blockquote>
<p>If you really insist on running ctags separately on each directory, you can
avoid the sort pass each time by specifying the option <tt class="docutils literal"><span class="pre">--sort=no</span></tt>. 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.</p>
</div>
<div class="section" id="how-should-i-set-up-tag-files-for-a-multi-level-directory-hierarchy">
<h2><a class="toc-backref" href="#id11">How should I set up tag files for a multi-level directory hierarchy?</a></h2>
<p>There are a few ways of approaching this:</p>
<ol class="arabic simple">
<li>A local tag file in each directory containing only the tags for source
files in that directory.</li>
<li>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.</li>
<li>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.</li>
<li>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).</li>
</ol>
<p>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:</p>
<ol class="upperalpha">
<li><p class="first">The ability of your editor to use multiple tag files.</p>
<p>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.</p>
</li>
<li><p class="first">The time is takes for your editor to look up a tag in the tag file.</p>
<p>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.</p>
</li>
<li><p class="first">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.</p>
<p>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.</p>
</li>
<li><p class="first">The presence of duplicate tags in the source code and the ability to
handle them.</p>
<p>The impact of this factor is influenced by the following three issues:</p>
<ol class="arabic">
<li><p class="first">How common are duplicate tags in your project?</p>
</li>
<li><p class="first">Does your editor provide any facilities for dealing with duplicate
tags?</p>
<p>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).</p>
</li>
<li><p class="first">What is the significance of duplicate tags?</p>
<p>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.</p>
</li>
</ol>
</li>
</ol>
<p>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.</p>
<p>The advantages of Approach 3 are many (assuming that your editor has
the ability to support both multiple tag files and duplicate tags). All
lookups of tag located in the current directory are fast and the local
tag file can be quickly and easily regenerated in one second or less
(I have even mapped a keystroke to do this easily). A lookup of a
(necessarily non-static) tag found in another directory fails a lookup in
the local tag file, but is found in the global tag file, which satisfies
all cross-directory lookups. The global tag file can be automatically
regenerated periodically with a cron job (and perhaps the local tag files
also).</p>
<p>Now I give an example of how you would implement Approach 3. Means of
implementing the other approaches can be performed in a similar manner.</p>
<p>Here is a visual representation of an example directory hierarchy:</p>
<pre class="literal-block">
project
`-----misccomp
| `...
`-----sysint
`-----client
| `-----hdrs
| `-----lib
| `-----src
| `-----test
`-----common
| `-----hdrs
| `-----lib
| `-----src
| `-----test
`-----server
`-----hdrs
`-----lib
`-----src
`-----test
</pre>
<p>Here is a recommended solution (conceptually) to build the tag files:</p>
<ol class="arabic">
<li><p class="first">Within each of the leaf nodes (i.e. <tt class="docutils literal">hdrs</tt>, <tt class="docutils literal">lib</tt>, <tt class="docutils literal">src</tt>, <tt class="docutils literal">test</tt>) build a tag
file using "<tt class="docutils literal">ctags <span class="pre">*.[ch]</span></tt>". This can be easily be done for the whole
hierarchy by making a shell script, call it <tt class="docutils literal">dirtags</tt>, containing the
following lines:</p>
<blockquote>
<pre class="code sh literal-block">
<span class="comment hashbang">#!/bin/sh
</span><span class="name builtin">cd</span> <span class="name variable">$1</span>
ctags *
</pre>
</blockquote>
<p>Now execute the following command:</p>
<blockquote>
<pre class="code sh literal-block">
find * -type d -exec dirtags <span class="operator">{}</span> <span class="literal string escape">\;</span>
</pre>
</blockquote>
<p>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:</p>
<blockquote>
<pre class="code text literal-block">
:nmap ,t :!(cd %:p:h;ctags *.[ch])&<CR><CR>
</pre>
</blockquote>
</li>
<li><p class="first">Build the global tag file:</p>
<blockquote>
<pre class="code sh literal-block">
<span class="name builtin">cd</span> ~/project
ctags --file-scope<span class="operator">=</span>no -R
</pre>
</blockquote>
<p>thus constructing a tag file containing only non-static tags for all
source files in all descendent directories.</p>
</li>
<li><p class="first">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:</p>
<blockquote>
<pre class="code text literal-block">
:set tags=./tags,tags,~/project/tags
</pre>
</blockquote>
</li>
</ol>
<p>If you wish to implement Approach 4, you would need to replace the
<tt class="docutils literal">dirtags</tt> script of step 1 with the following:</p>
<blockquote>
<pre class="code sh literal-block">
<span class="comment hashbang">#!/bin/sh
</span><span class="name builtin">cd</span> <span class="name variable">$1</span>
ctags *
<span class="comment single"># Now append the non-static tags from descendent directories
</span>find * -type d -prune -print <span class="punctuation">|</span> ctags -aR --file-scope<span class="operator">=</span>no -L-
</pre>
</blockquote>
<p>And replace the configuration of step 3 with this:</p>
<blockquote>
<pre class="code text literal-block">
:set tags=./tags;$HOME,tags
</pre>
</blockquote>
<p>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 <tt class="docutils literal">tagrelative</tt> 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:</p>
<blockquote>
<pre class="code sh literal-block">
<span class="name builtin">cd</span> ~/project
ctags --file-scope<span class="operator">=</span>no -R <span class="literal string backtick">`</span><span class="name builtin">pwd</span><span class="literal string backtick">`</span>
</pre>
</blockquote>
</div>
<div class="section" id="does-universal-ctags-support-unicode-file-names">
<h2><a class="toc-backref" href="#id12">Does Universal Ctags support Unicode file names?</a></h2>
<!-- MEMO: from https://github.com/universal-ctags/ctags/issues/1837 -->
<p>Yes, Unicode file names are supported on unix-like platforms (Linux, macOS,
Cygwin, etc.).</p>
<p>However, on Windows, you need to use Windows 10 version 1903 or later to use
Unicode file names. (This is an experimental feature, though.) 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.</p>
</div>
<div class="section" id="why-does-zsh-cause-zsh-no-matches-found-error">
<h2><a class="toc-backref" href="#id13">Why does zsh cause "zsh: no matches found" error?</a></h2>
<!-- MEMO: from https://github.com/universal-ctags/ctags/issues/2842 -->
<p>zsh causes error on the following cases;</p>
<blockquote>
<pre class="code sh literal-block">
ctags --extra<span class="operator">=</span>+* ...
ctags --exclude<span class="operator">=</span>foo/* ...
</pre>
</blockquote>
<p>This is the 2nd most significant incompatibility <em>feature</em> of zsh.</p>
<p>Cited from "Z-Shell Frequently-Asked Questions", "<a class="reference external" href="http://zsh.sourceforge.net/FAQ/zshfaq02.html">2.1: Differences from sh and
ksh</a>";</p>
<blockquote>
... The next most classic difference is that unmatched glob patterns cause
the command to abort; set <tt class="docutils literal">NO_NOMATCH</tt> for those.</blockquote>
<p>You may add "<tt class="docutils literal">setopt nonomatch</tt>" on your <tt class="docutils literal"><span class="pre">~/.zshrc</span></tt>. Or you can escape glob
patterns with backslash;</p>
<blockquote>
<pre class="code sh literal-block">
ctags --extra<span class="operator">=</span>+<span class="literal string escape">\*</span> ...
ctags --exclude<span class="operator">=</span>foo/<span class="literal string escape">\*</span> ...
</pre>
</blockquote>
<p>Or quote them;</p>
<blockquote>
<pre class="code sh literal-block">
ctags <span class="literal string single">'--extra=+*'</span> ...
ctags <span class="literal string single">'--exclude=foo/*'</span> ...
</pre>
</blockquote>
</div>
</div>
<div class="section" id="see-also">
<h1><a class="toc-backref" href="#id14">SEE ALSO</a></h1>
<p>The official Universal Ctags web site at:</p>
<p><a class="reference external" href="https://ctags.io/">https://ctags.io/</a></p>
<p>ctags(1), tags(5)</p>
</div>
<div class="section" id="author">
<h1><a class="toc-backref" href="#id15">AUTHOR</a></h1>
<p>This FAQ is based on <a class="reference external" href="http://ctags.sourceforge.net/faq.html">Exuberant Ctags FAQ</a> by
Darren Hiebert and <a class="reference external" href="mailto:vberthoux@users.sourceforge.net">vberthoux@users.sourceforge.net</a></p>
<p>Universal Ctags project: <a class="reference external" href="https://ctags.io/">https://ctags.io/</a></p>
</div>
</div>
</body>
</html>
|
