|
@@ -0,0 +1,728 @@
|
|
1
|
+*gutentags.txt* Automatic ctags management for VIM
|
|
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
|
+ GUTENTAGS REFERENCE MANUAL
|
|
27
|
+ by Ludovic Chabant
|
|
28
|
+
|
|
29
|
+ *gutentags*
|
|
30
|
+
|
|
31
|
+1. Introduction |gutentags-intro|
|
|
32
|
+2. Commands |gutentags-commands|
|
|
33
|
+3. Status Line |gutentags-status-line|
|
|
34
|
+4. Global Settings |gutentags-settings|
|
|
35
|
+5. Project Settings |gutentags-project-settings|
|
|
36
|
+
|
|
37
|
+=============================================================================
|
|
38
|
+1. Introduction *gutentags-intro*
|
|
39
|
+
|
|
40
|
+Gutentags is a plugin that takes care of the much needed management of tags
|
|
41
|
+files in Vim. It will (re)generate tag files as you work while staying
|
|
42
|
+completely out of your way. It will even do its best to keep those tag files
|
|
43
|
+out of your way too. It has no dependencies and just works.
|
|
44
|
+
|
|
45
|
+In order to generate tag files, Gutentags will have to figure out what's in
|
|
46
|
+your project. To do this, it will locate well-known project root markers like
|
|
47
|
+SCM folders (.git, .hg, etc.), any custom tags you define (with
|
|
48
|
+|gutentags_project_root|), and even things you may have defined already with
|
|
49
|
+other plugins, like CtrlP.
|
|
50
|
+
|
|
51
|
+If the current file you're editing is found to be in such a project, Gutentags
|
|
52
|
+will make sure the tag file for that project is up to date. Then, as you work
|
|
53
|
+in files in that project, it will partially re-generate the tag file. Every
|
|
54
|
+time you save, it will silently, in the background, update the tags for that
|
|
55
|
+file.
|
|
56
|
+
|
|
57
|
+Usually, `ctags` can only append tags to an existing tag file, so Gutentags
|
|
58
|
+removes the tags for the current file first, to make sure the tag file is
|
|
59
|
+always consistent with the source code.
|
|
60
|
+
|
|
61
|
+Also, Gutentags is clever enough to not stumble upon itself by triggering
|
|
62
|
+multiple ctags processes if you save files too fast, or if your project is
|
|
63
|
+really big.
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+1.1 Requirements
|
|
67
|
+ *gutentags-ctags-requirements*
|
|
68
|
+
|
|
69
|
+If you're using the `ctags` modules (which is the default and only working one
|
|
70
|
+at this point, really), you will need a `tags` generator that supports the
|
|
71
|
+following arguments:
|
|
72
|
+
|
|
73
|
+* `-f` (to specify the output file)
|
|
74
|
+* `--append` (to append to an existing file while keeping it sorted)
|
|
75
|
+* `--exclude` (to exclude file patterns)
|
|
76
|
+* `--options` (to specify an options file)
|
|
77
|
+
|
|
78
|
+This means you probably want Exuberant Ctags or Universal Ctags. The basic
|
|
79
|
+old BSD Ctags WON'T WORK. Other language-specific versions may or may not
|
|
80
|
+work. Check with their help or man page.
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+1.2 Similar Plugins
|
|
84
|
+ *gutentags-similar-plugins*
|
|
85
|
+
|
|
86
|
+There are some similar Vim plugins out there ("vim-tags", "vim-autotag",
|
|
87
|
+"vim-automatic-ctags", etc.). They all fail on one or more of the requirements
|
|
88
|
+I set for myself with Gutentags:
|
|
89
|
+
|
|
90
|
+* No other dependency than running Vim: no Python, Ruby, or whatever.
|
|
91
|
+* Cross-platform: should work on at least Mac and Windows.
|
|
92
|
+* Incremental tags generation: don't re-generate the whole project all the
|
|
93
|
+ time. This may be fine for small projects, but it doesn't scale.
|
|
94
|
+* External process management: if the ctags process is taking a long time,
|
|
95
|
+ don't run another one because I saved the file again.
|
|
96
|
+* Keep the tag file consistent: don't just append the current file's tags to
|
|
97
|
+ the tag file, otherwise you will still "see" tags for deleted or renamed
|
|
98
|
+ classes and functions.
|
|
99
|
+* Automatically create the tag file: you open something from a freshly forked
|
|
100
|
+ project, it should start indexing it automatically, just like in Sublime Text
|
|
101
|
+ or Visual Studio or any other IDE.
|
|
102
|
+
|
|
103
|
+
|
|
104
|
+=============================================================================
|
|
105
|
+2. Commands *gutentags-commands*
|
|
106
|
+
|
|
107
|
+ *gutentags-project-commands*
|
|
108
|
+The following commands are only available in buffers that have been found to
|
|
109
|
+belong to a project that should be managed by Gutentags. See
|
|
110
|
+|gutentags_project_root| for how Gutentags figures out the project a file
|
|
111
|
+belongs to. When no project is found (i.e. the file is not under any of the
|
|
112
|
+known project markers), Gutentags is disabled for that buffer, and the
|
|
113
|
+following commands and remarks don't apply.
|
|
114
|
+
|
|
115
|
+If you want to force-disable Gutentags for a given project even though it does
|
|
116
|
+match one of the items in |gutentags_project_root|, create a file named
|
|
117
|
+"`.notags`" at the root of the project.
|
|
118
|
+
|
|
119
|
+The tag file that Gutentags creates and manages will be named after
|
|
120
|
+|gutentags_ctags_tagfile|, relative to the project's root directory. When
|
|
121
|
+Gutentags finds a valid project root, it will prepend the tag file's path to
|
|
122
|
+'tags', unless |gutentags_ctags_auto_set_tags| is set to 0. This is to make
|
|
123
|
+sure Vim will use that file first.
|
|
124
|
+
|
|
125
|
+If a file managed by Gutentags is opened and no tag file already exists,
|
|
126
|
+Gutentags will start generating it right away in the background, unless
|
|
127
|
+|gutentags_generate_on_missing| is set to 0. If you have a large project, you
|
|
128
|
+may want to know when Gutentags is generating tags: see
|
|
129
|
+|gutentags-status-line| to display an indicator in your status line.
|
|
130
|
+
|
|
131
|
+When a file managed by Gutentags is saved, the tag file will be incrementally
|
|
132
|
+updated, i.e. references to the recently saved file are removed, and that file
|
|
133
|
+is re-parsed for tags, with the result being merged into the tag file. This
|
|
134
|
+makes the tag file 100% consistent with the latest changes. This doesn't
|
|
135
|
+happen however if |gutentags_generate_on_write| is set to 0, in which case you
|
|
136
|
+have to run |GutentagsUpdate| manually.
|
|
137
|
+
|
|
138
|
+
|
|
139
|
+ *:GutentagsUpdate*
|
|
140
|
+:GutentagsUpdate
|
|
141
|
+ Forces an update of the current tag file with the
|
|
142
|
+ current buffer. If tags are already being generated,
|
|
143
|
+ you will be notified and the command will abort.
|
|
144
|
+
|
|
145
|
+:GutentagsUpdate!
|
|
146
|
+ Like |GutentagsUpdate|, but updates the current tags
|
|
147
|
+ file with the whole project instead of just the
|
|
148
|
+ current buffer.
|
|
149
|
+
|
|
150
|
+
|
|
151
|
+Some debugging/troubleshooting commands are also available if the
|
|
152
|
+|gutentags_define_advanced_commands| global setting is set to 1.
|
|
153
|
+
|
|
154
|
+ *:GutentagsToggleEnabled*
|
|
155
|
+:GutentagsToggleEnabled
|
|
156
|
+ Disables and re-enables Gutentags.
|
|
157
|
+ When Gutentags is disabled, it won't update your tag
|
|
158
|
+ file when you save a buffer. It will however still
|
|
159
|
+ look for project markers as you open new buffers so
|
|
160
|
+ that they can start working again when you re-enable
|
|
161
|
+ Gutentags.
|
|
162
|
+
|
|
163
|
+ {only available when
|
|
164
|
+ |gutentags_define_advanced_commands| is set}
|
|
165
|
+
|
|
166
|
+ *GutentagsToggleTrace*
|
|
167
|
+:GutentagsToggleTrace
|
|
168
|
+ If you want to keep an eye on what Gutentags is doing,
|
|
169
|
+ you can enable tracing. This will show messages every
|
|
170
|
+ time Gutentags does something. It can get annoying
|
|
171
|
+ quickly, since it will require you to press a key to
|
|
172
|
+ dismiss those messages, but it can be useful to
|
|
173
|
+ troubleshoot a problem.
|
|
174
|
+ In addition to messages in Vim, it will also make
|
|
175
|
+ Gutentags redirect the output of the tag generation
|
|
176
|
+ script to a `.log` file in the project root.
|
|
177
|
+
|
|
178
|
+ {only available when
|
|
179
|
+ |gutentags_define_advanced_commands| is set}
|
|
180
|
+
|
|
181
|
+
|
|
182
|
+Gutentags also has some user auto-commands (see |User| and |:doautocmd|):
|
|
183
|
+
|
|
184
|
+ *GutentagsUpdating*
|
|
185
|
+GutentagsUpdating
|
|
186
|
+ This auto-command is triggered when a background
|
|
187
|
+ update job has started.
|
|
188
|
+
|
|
189
|
+ *GutentagsUpdated*
|
|
190
|
+GutentagsUpdated
|
|
191
|
+ This auto-command is triggered when a background
|
|
192
|
+ update job has finished.
|
|
193
|
+
|
|
194
|
+
|
|
195
|
+=============================================================================
|
|
196
|
+3. Status Line *gutentags-status-line*
|
|
197
|
+
|
|
198
|
+Tag file generation can take a while if you're working on a project big
|
|
199
|
+enough. In that case, you may want to know when `ctags` is running, so you
|
|
200
|
+have a heads up if some of the tags aren't recognized yet.
|
|
201
|
+
|
|
202
|
+ *gutentags#statusline()*
|
|
203
|
+You can display an indicator of tag generation progress in your |status-line|
|
|
204
|
+with the following function: >
|
|
205
|
+ :set statusline+=%{gutentags#statusline()}
|
|
206
|
+
|
|
207
|
+The function will, by default, print a list of modules in the status line. So
|
|
208
|
+if the `ctags` module (see |g:gutentags_modules|) is currently generating
|
|
209
|
+a tags file, you will see "ctags" printed in the status line. If nothing is
|
|
210
|
+happening, nothing will be printed in the status line.
|
|
211
|
+
|
|
212
|
+You can pass some parameters to customize this:
|
|
213
|
+
|
|
214
|
+1. A prefix string (defaults to `""`).
|
|
215
|
+2. A suffix string (defaults to `""`).
|
|
216
|
+3. The text to print (defaults to the names of modules currently generating
|
|
217
|
+ something).
|
|
218
|
+
|
|
219
|
+So using `gutentags#statusline('[', ']')` would print `"[ctags]"` instead of
|
|
220
|
+`"ctags"`.
|
|
221
|
+
|
|
222
|
+Because Gutentags runs the tag generation in the background, the statusline
|
|
223
|
+indicator might stay there even after the background process has ended. It
|
|
224
|
+would only go away when Vim decides to refresh the statusline. You can force
|
|
225
|
+refresh it in a callback on |GutentagsUpdating| and |GutentagsUpdated|.
|
|
226
|
+
|
|
227
|
+For instance, with the `lightline` plugin:
|
|
228
|
+
|
|
229
|
+ augroup MyGutentagsStatusLineRefresher
|
|
230
|
+ autocmd!
|
|
231
|
+ autocmd User GutentagsUpdating call lightline#update()
|
|
232
|
+ autocmd User GutentagsUpdated call lightline#update()
|
|
233
|
+ augroup END
|
|
234
|
+
|
|
235
|
+ *gutentags#statusline_cb*
|
|
236
|
+As an alternative to the previous function, `gutentags#statusline_cb` takes
|
|
237
|
+a single parameter which should be a |Funcref| or a function name. This
|
|
238
|
+function should take a list of active module names, and return a string. This
|
|
239
|
+lets you completely control what the status line will print.
|
|
240
|
+
|
|
241
|
+For instance:
|
|
242
|
+ function! s:get_gutentags_status(mods) abort
|
|
243
|
+ let l:msg = ''
|
|
244
|
+ if index(a:mods, 'ctags') >= 0
|
|
245
|
+ let l:msg .= '♨'
|
|
246
|
+ endif
|
|
247
|
+ if index(a:mods, 'cscope') >= 0
|
|
248
|
+ let l:msg .= '♺'
|
|
249
|
+ endif
|
|
250
|
+ return l:msg
|
|
251
|
+ endfunction
|
|
252
|
+
|
|
253
|
+ :set statusline+=%{gutentags#statusline_cb(
|
|
254
|
+ \function('<SID>get_gutentags_status'))}
|
|
255
|
+
|
|
256
|
+By default, the callback function doesn't get called if no tags generation is
|
|
257
|
+currently happening. You can pass `1` as a second argument so that the
|
|
258
|
+callback function is always called.
|
|
259
|
+
|
|
260
|
+
|
|
261
|
+=============================================================================
|
|
262
|
+4. Global Settings *gutentags-settings*
|
|
263
|
+
|
|
264
|
+The following settings can be defined in your |vimrc| to change the default
|
|
265
|
+behaviour of Gutentags.
|
|
266
|
+
|
|
267
|
+ *gutentags_enabled*
|
|
268
|
+g:gutentags_enabled
|
|
269
|
+ Defines whether Gutentags should be enabled. When
|
|
270
|
+ disabled, Gutentags will still scan for project root
|
|
271
|
+ markers when opening buffers. This is so that when you
|
|
272
|
+ re-enable Gutentags, you won't have some buffers
|
|
273
|
+ mysteriously working while others (those open last)
|
|
274
|
+ don't.
|
|
275
|
+ Defaults to `1`.
|
|
276
|
+
|
|
277
|
+ *gutentags_trace*
|
|
278
|
+g:gutentags_trace
|
|
279
|
+ When true, Gutentags will spit out debugging
|
|
280
|
+ information as Vim messages (which you can later read
|
|
281
|
+ with |:messages|). It also runs its background scripts
|
|
282
|
+ with extra parameters to log activity to a `tags.log`
|
|
283
|
+ file that you can also inspect for more information.
|
|
284
|
+
|
|
285
|
+ Note: you can run `:verbose GutentagsUpdate` to
|
|
286
|
+ temporarily set |g:gutentags_trace| to `1` for that
|
|
287
|
+ update only.
|
|
288
|
+
|
|
289
|
+ Defaults to `0`.
|
|
290
|
+
|
|
291
|
+ *gutentags_dont_load*
|
|
292
|
+g:gutentags_dont_load
|
|
293
|
+ Prevents Gutentags from loading at all on Vim startup.
|
|
294
|
+
|
|
295
|
+ The difference between this and |gutentags_enabled| is
|
|
296
|
+ that |gutentags_enabled| can be turned on and off in
|
|
297
|
+ the same Vim session -- Gutentags as a plugin stays
|
|
298
|
+ loaded and will keep track of what happened while it
|
|
299
|
+ was disabled. However, |gutentags_dont_load| only
|
|
300
|
+ works on Vim startup and will prevent Gutentags from
|
|
301
|
+ loading at all, as if it wasn't there.
|
|
302
|
+
|
|
303
|
+ *gutentags_modules*
|
|
304
|
+g:gutentags_modules
|
|
305
|
+ A list of modules to load with Gutentags. Each module
|
|
306
|
+ is responsible for generating a specific type of tags
|
|
307
|
+ file.
|
|
308
|
+ Valid values are:
|
|
309
|
+
|
|
310
|
+ - `ctags`: generates a `tags` file using
|
|
311
|
+ a `ctags`-compatible program like Exhuberant Ctags
|
|
312
|
+ or Universal Ctags.
|
|
313
|
+
|
|
314
|
+ - `cscope`: generates a code database file using
|
|
315
|
+ `cscope`.
|
|
316
|
+
|
|
317
|
+ - `gtags_cscope`: same as `cscope` but uses GNU's
|
|
318
|
+ `gtags` executable and database.
|
|
319
|
+
|
|
320
|
+ Defaults to `[ctags]`.
|
|
321
|
+
|
|
322
|
+ *gutentags_project_root*
|
|
323
|
+g:gutentags_project_root
|
|
324
|
+ When a buffer is loaded, Gutentags will figure out if
|
|
325
|
+ it's part of a project that should have tags managed
|
|
326
|
+ automatically. To do this, it looks for "root markers"
|
|
327
|
+ in the current file's directory and its parent
|
|
328
|
+ directories. If it finds any of those markers,
|
|
329
|
+ Gutentags will be enabled for the project, and a tags
|
|
330
|
+ file named after |gutentags_ctags_tagfile| will be
|
|
331
|
+ created at the project root.
|
|
332
|
+ Defaults to `[]` (an empty |List|).
|
|
333
|
+ A list of default markers will be appended to the
|
|
334
|
+ user-defined ones unless
|
|
335
|
+ |gutentags_add_default_project_roots| is set to 0.
|
|
336
|
+
|
|
337
|
+ *gutentags_add_default_project_roots*
|
|
338
|
+g:gutentags_add_default_project_roots
|
|
339
|
+ Defines whether Gutentags should always define some
|
|
340
|
+ default project roots (see |gutentags_project_root|).
|
|
341
|
+ This can be useful to prevent unnecessary disk access
|
|
342
|
+ when Gutentags searches for a project root.
|
|
343
|
+ The default markers are:
|
|
344
|
+ `['.git', '.hg', '.svn', '.bzr', '_darcs', '_darcs', '_FOSSIL_', '.fslckout']`
|
|
345
|
+
|
|
346
|
+ *gutentags_add_ctrlp_root_markers*
|
|
347
|
+g:gutentags_add_ctrlp_root_markers
|
|
348
|
+ If Gutentags finds `g:ctrlp_root_markers` (used by the
|
|
349
|
+ CtrlP plugin), it will append those root markers to
|
|
350
|
+ the existing ones (see |g:gutentags_project_root|).
|
|
351
|
+ Set this to 0 to stop it from happening.
|
|
352
|
+ Defaults to 1.
|
|
353
|
+
|
|
354
|
+ *gutentags_exclude_filetypes*
|
|
355
|
+g:gutentags_exclude_filetypes
|
|
356
|
+ A |List| of file types (see |'filetype'|) that Gutentags
|
|
357
|
+ should ignore. When a buffer is opened, if its
|
|
358
|
+ 'filetype' is found in this list, Gutentags features
|
|
359
|
+ won't be available for this buffer.
|
|
360
|
+ Defaults to an empty list (`[]`).
|
|
361
|
+
|
|
362
|
+ *gutentags_exclude_project_root*
|
|
363
|
+g:gutentags_exclude_project_root
|
|
364
|
+ A list of project roots to generally ignore. If a file
|
|
365
|
+ is opened inside one of those projects, Gutentags
|
|
366
|
+ won't be activated. This is similar to placing
|
|
367
|
+ a `.notags` file in the root of those projects, but
|
|
368
|
+ can be useful when you don't want to, or can't, place
|
|
369
|
+ such a file there.
|
|
370
|
+ Defaults to `['/usr/local']`, which is the folder where
|
|
371
|
+ Homebrew is known to create a Git directory by default
|
|
372
|
+ on MacOS.
|
|
373
|
+
|
|
374
|
+ *gutentags_project_root_finder*
|
|
375
|
+g:gutentags_project_root_finder
|
|
376
|
+ When a buffer is loaded, Gutentags uses a default
|
|
377
|
+ (internal) implementation to find that file's
|
|
378
|
+ project's root directory, using settings like
|
|
379
|
+ |g:gutentags_project_root|. When you specify
|
|
380
|
+ |g:gutentags_project_root_finder|, you can tell
|
|
381
|
+ Gutentags to use a custom implementation, such as
|
|
382
|
+ `vim-projectroot`. The value of this setting must be
|
|
383
|
+ the name of a function that takes a single string
|
|
384
|
+ argument (the path to the current buffer's file) and
|
|
385
|
+ returns a string value (the project's root directory).
|
|
386
|
+ Defaults to `''`.
|
|
387
|
+ Note: when set, the called implementation will
|
|
388
|
+ possibly ignore |g:gutentags_project_root|.
|
|
389
|
+ Note: an implementation can fallback to the default
|
|
390
|
+ behaviour by calling
|
|
391
|
+ `gutentags#default_get_project_root`.
|
|
392
|
+
|
|
393
|
+ *gutentags_generate_on_missing*
|
|
394
|
+g:gutentags_generate_on_missing
|
|
395
|
+ If set to 1, Gutentags will start generating an initial
|
|
396
|
+ tag file if a file is open in a project where no tags
|
|
397
|
+ file is found. See |gutentags_project_root| for how
|
|
398
|
+ Gutentags locates the project.
|
|
399
|
+ When set to 0, Gutentags will only generate the first
|
|
400
|
+ time the file is saved (if
|
|
401
|
+ |gutentags_generate_on_write| is set to 1), or when
|
|
402
|
+ |GutentagsUpdate| or |GutentagsGenerate| is run.
|
|
403
|
+ Defaults to 1.
|
|
404
|
+
|
|
405
|
+ *gutentags_generate_on_new*
|
|
406
|
+g:gutentags_generate_on_new
|
|
407
|
+ If set to 1, Gutentags will start generating the tag
|
|
408
|
+ file when a new project is open. A new project is
|
|
409
|
+ considered open when a buffer is created for a file
|
|
410
|
+ whose corresponding tag file has not been "seen" yet
|
|
411
|
+ in the current Vim session -- which pretty much means
|
|
412
|
+ when you open the first file in a given source control
|
|
413
|
+ repository.
|
|
414
|
+ When set to 0, Gutentags won't do anything special.
|
|
415
|
+ See also |gutentags_generate_on_missing| and
|
|
416
|
+ |gutentags_generate_on_write|.
|
|
417
|
+ Defaults to 1.
|
|
418
|
+
|
|
419
|
+ *gutentags_generate_on_write*
|
|
420
|
+g:gutentags_generate_on_write
|
|
421
|
+ If set to 1, Gutentags will update the current
|
|
422
|
+ project's tag file when a file inside that project is
|
|
423
|
+ saved. See |gutentags_project_root| for how Gutentags
|
|
424
|
+ locates the project.
|
|
425
|
+ When set to 0, Gutentags won't do anything on save.
|
|
426
|
+ This means that the project's tag file won't reflect
|
|
427
|
+ the latest changes, and you will have to run
|
|
428
|
+ |GutentagsUpdate| manually.
|
|
429
|
+ Defaults to 1.
|
|
430
|
+
|
|
431
|
+ *gutentags_generate_on_empty_buffer*
|
|
432
|
+g:gutentags_generate_on_empty_buffer
|
|
433
|
+ If set to 1, Gutentags will start generating the tag
|
|
434
|
+ file even if there's no buffer currently open, as long
|
|
435
|
+ as the current working directory (as returned by
|
|
436
|
+ |:cd|) is inside a known project.
|
|
437
|
+ This is useful if you want Gutentags to generate the
|
|
438
|
+ tag file right after opening Vim.
|
|
439
|
+ Defaults to 0.
|
|
440
|
+
|
|
441
|
+ *gutentags_background_update*
|
|
442
|
+g:gutentags_background_update
|
|
443
|
+ Specifies whether the process that updates the tags
|
|
444
|
+ file should be run in the background or in the
|
|
445
|
+ foreground. If run in the foreground, Vim will block
|
|
446
|
+ until the process is complete.
|
|
447
|
+ Defaults to 1.
|
|
448
|
+
|
|
449
|
+ *gutentags_cache_dir*
|
|
450
|
+g:gutentags_cache_dir
|
|
451
|
+ Specifies a directory in which to create all the tags
|
|
452
|
+ files, instead of writing them at the root of each
|
|
453
|
+ project. This is handy to keep tags files from
|
|
454
|
+ polluting many directories all across your computer.
|
|
455
|
+
|
|
456
|
+ *gutentags_resolve_symlinks*
|
|
457
|
+g:gutentags_resolve_symlinks
|
|
458
|
+ When set to 1, Gutentags will resolve any symlinks in
|
|
459
|
+ the current buffer's path in order to find the project
|
|
460
|
+ it belongs to. This is what you want if you're editing
|
|
461
|
+ a symlink located outside of the project, and it
|
|
462
|
+ points to a file inside the project. However, this is
|
|
463
|
+ maybe not what you want if the symlink itself is
|
|
464
|
+ part of the project.
|
|
465
|
+ Defaults to 0.
|
|
466
|
+
|
|
467
|
+ *gutentags_init_user_func*
|
|
468
|
+g:gutentags_init_user_func
|
|
469
|
+ When set to a non-empty string, it is expected to be
|
|
470
|
+ the name of a function that will be called when a file
|
|
471
|
+ is opened in a project. The function gets passed the
|
|
472
|
+ path of the file and if it returns 0, Gutentags won't
|
|
473
|
+ be enabled for that file.
|
|
474
|
+
|
|
475
|
+ You can use this to manually set buffer-local
|
|
476
|
+ settings:
|
|
477
|
+
|
|
478
|
+ * `b:gutentags_ctags_tagfile` (see |gutentags_ctags_tagfile|).
|
|
479
|
+
|
|
480
|
+ This setting was previously called
|
|
481
|
+ `gutentags_enabled_user_func`. The old setting is
|
|
482
|
+ still used as a fallback.
|
|
483
|
+
|
|
484
|
+ Defaults to "".
|
|
485
|
+
|
|
486
|
+ *gutentags_define_advanced_commands*
|
|
487
|
+g:gutentags_define_advanced_commands
|
|
488
|
+ Defines some advanced commands like
|
|
489
|
+ |GutentagsToggleEnabled| and |GutentagsUnlock|.
|
|
490
|
+
|
|
491
|
+ *gutentags_project_info*
|
|
492
|
+g:gutentags_project_info
|
|
493
|
+ Defines ways for Gutentags to figure out what kind of
|
|
494
|
+ project any given file belongs to. This should be
|
|
495
|
+ a list of dictionaries:
|
|
496
|
+
|
|
497
|
+ let g:gutentags_project_info = []
|
|
498
|
+ call add(g:gutentags_project_info, {...})
|
|
499
|
+
|
|
500
|
+ Each dictionary item must contain at least a `type`
|
|
501
|
+ key, indicating the type of project:
|
|
502
|
+
|
|
503
|
+ {"type": "python"}
|
|
504
|
+
|
|
505
|
+ Other items will be used to figure out if a project is
|
|
506
|
+ of the given type.
|
|
507
|
+
|
|
508
|
+ "file": any existing file with this path (relative to
|
|
509
|
+ the project root) will make the current project match
|
|
510
|
+ the given info.
|
|
511
|
+
|
|
512
|
+ "glob": any result found with this glob pattern
|
|
513
|
+ (relative to the project root) will make the current
|
|
514
|
+ project match the given info. See |glob()| for more
|
|
515
|
+ information.
|
|
516
|
+
|
|
517
|
+ Gutentags adds by default the following definitions:
|
|
518
|
+
|
|
519
|
+ call add(g:gutentags_project_info, {'type': 'python', 'file': 'setup.py'})
|
|
520
|
+ call add(g:gutentags_project_info, {'type': 'ruby', 'file': 'Gemfile'})
|
|
521
|
+
|
|
522
|
+ This means, for example, that you can use
|
|
523
|
+ `g:gutentags_ctags_executable_ruby` out of the box.
|
|
524
|
+ See |gutentags_ctags_executable_{filetype}| for more
|
|
525
|
+ information.
|
|
526
|
+
|
|
527
|
+ *gutentags_file_list_command*
|
|
528
|
+g:gutentags_file_list_command
|
|
529
|
+ Specifies command(s) to use to list files for which
|
|
530
|
+ tags should be generated, instead of recursively
|
|
531
|
+ examining all files within the project root. When
|
|
532
|
+ invoked, file list commands will execute in the
|
|
533
|
+ project root directory.
|
|
534
|
+
|
|
535
|
+ This setting is useful in projects using source
|
|
536
|
+ control to restrict tag generation to only files
|
|
537
|
+ tracked in the repository.
|
|
538
|
+
|
|
539
|
+ This variable may be set in one of two ways. If
|
|
540
|
+ set as a |String|, the specified command will be used to
|
|
541
|
+ list files for all projects. For example: >
|
|
542
|
+
|
|
543
|
+ let g:gutentags_file_list_command = 'find . -type f'
|
|
544
|
+<
|
|
545
|
+ If set as a |Dictionary|, this variable should be set
|
|
546
|
+ as a mapping of project root markers to the desired
|
|
547
|
+ file list command for that root marker. (See
|
|
548
|
+ |gutentags_project_root| for how Gutentags uses root
|
|
549
|
+ markers to locate the project.) For example: >
|
|
550
|
+
|
|
551
|
+ let g:gutentags_file_list_command = {
|
|
552
|
+ \ 'markers': {
|
|
553
|
+ \ '.git': 'git ls-files',
|
|
554
|
+ \ '.hg': 'hg files',
|
|
555
|
+ \ },
|
|
556
|
+ \ }
|
|
557
|
+<
|
|
558
|
+ Note: If a custom ctags executable is specified, it
|
|
559
|
+ must support the '-L' command line option in order to
|
|
560
|
+ read the list of files to be examined.
|
|
561
|
+
|
|
562
|
+
|
|
563
|
+The following settings are valid for the `ctags` module.
|
|
564
|
+
|
|
565
|
+ *gutentags_ctags_executable*
|
|
566
|
+g:gutentags_ctags_executable
|
|
567
|
+ Specifies the ctags executable to launch.
|
|
568
|
+ Defaults to `ctags`.
|
|
569
|
+
|
|
570
|
+ *gutentags_ctags_executable_{filetype}*
|
|
571
|
+g:gutentags_ctags_executable_{type}
|
|
572
|
+ Specifies the ctags executable to launch for a project
|
|
573
|
+ of type {type}. See |gutentags_project_info| for more
|
|
574
|
+ information.
|
|
575
|
+ IMPORTANT: please see |gutentags-ctags-requirements|.
|
|
576
|
+ Example: >
|
|
577
|
+ let g:gutentags_ctags_executable_ruby = 'foobar'
|
|
578
|
+<
|
|
579
|
+
|
|
580
|
+ *gutentags_ctags_tagfile*
|
|
581
|
+g:gutentags_ctags_tagfile
|
|
582
|
+ Specifies the name of the tag file to create. This
|
|
583
|
+ will be appended to the project's root. See
|
|
584
|
+ |gutentags_project_root| for how Gutentags locates the
|
|
585
|
+ project.
|
|
586
|
+ Defaults to `tags`.
|
|
587
|
+
|
|
588
|
+ *gutentags_ctags_exclude*
|
|
589
|
+g:gutentags_ctags_exclude
|
|
590
|
+ A list of file patterns to pass to the
|
|
591
|
+ |gutentags_ctags_executable| so that they will be
|
|
592
|
+ excluded from parsing for the tags generation.
|
|
593
|
+ See also |gutentags_ctags_exclude_wildignore|.
|
|
594
|
+ Defaults to `[]` (an empty |List|).
|
|
595
|
+
|
|
596
|
+ *gutentags_ctags_exclude_wildignore*
|
|
597
|
+g:gutentags_ctags_exclude_wildignore
|
|
598
|
+ When 1, Gutentags will automatically pass your
|
|
599
|
+ 'wildignore' file patterns to the
|
|
600
|
+ |gutentags_ctags_executable| so that they are ignored.
|
|
601
|
+ Set also |gutentags_ctags_exclude| to pass custom
|
|
602
|
+ patterns.
|
|
603
|
+ Defaults to 1.
|
|
604
|
+
|
|
605
|
+ *gutentags_ctags_auto_set_tags*
|
|
606
|
+g:gutentags_ctags_auto_set_tags
|
|
607
|
+ If set to 1, Gutentags will automatically prepend
|
|
608
|
+ 'tags' with the exact path to the tag file for the
|
|
609
|
+ current project. See |gutentags_project_root| for how
|
|
610
|
+ Gutentags locates the project.
|
|
611
|
+ When set to 0, Gutentags doesn't change 'tags', and
|
|
612
|
+ this means that whatever tag file it generates may
|
|
613
|
+ not be picked up by Vim. See |tagfiles()| to know what
|
|
614
|
+ tag files Vim knows about.
|
|
615
|
+ Defaults to 1.
|
|
616
|
+
|
|
617
|
+ *gutentags_ctags_extra_args*
|
|
618
|
+g:gutentags_ctags_extra_args
|
|
619
|
+ A list of arguments to pass to `ctags`.
|
|
620
|
+ Defaults to `[]`.
|
|
621
|
+
|
|
622
|
+ *gutentags_ctags_post_process_cmd*
|
|
623
|
+g:gutentags_ctags_post_process_cmd
|
|
624
|
+ If defined, the tags generation script will run the
|
|
625
|
+ command with an argument that points to a temporary
|
|
626
|
+ copy of the tags file. If the post-process step is
|
|
627
|
+ modifying the tags file, it needs to do so in-place.
|
|
628
|
+ This is useful for cleaning up a tags file that may
|
|
629
|
+ contain tags with non-ASCII names that somehow upsets
|
|
630
|
+ Vim.
|
|
631
|
+ Defaults to `""` (an empty |String|).
|
|
632
|
+
|
|
633
|
+
|
|
634
|
+The following settings are valid for the `cscope` module.
|
|
635
|
+
|
|
636
|
+ *gutentags_cscope_executable*
|
|
637
|
+g:gutentags_cscope_executable
|
|
638
|
+ Specifies the name or path of the `cscope` executable
|
|
639
|
+ to use to generate the code database.
|
|
640
|
+ Defaults to `"cscope"`.
|
|
641
|
+
|
|
642
|
+ *gutentags_scopefile*
|
|
643
|
+g:gutentags_scopefile
|
|
644
|
+ Specifies the name of the scope file to create. This
|
|
645
|
+ will be appended to the project's root. See
|
|
646
|
+ |gutentags_project_root| for how Gutentags locates the
|
|
647
|
+ project.
|
|
648
|
+ Defaults to `"cscope.out"`.
|
|
649
|
+
|
|
650
|
+ *gutentags_auto_add_cscope*
|
|
651
|
+g:gutentags_auto_add_cscope
|
|
652
|
+ If set to 1, Gutentags will automatically add the
|
|
653
|
+ generated code database to Vim by running `:cs add`
|
|
654
|
+ (see |:cscope|).
|
|
655
|
+ Defaults to 1.
|
|
656
|
+
|
|
657
|
+ *gutentags_cscope_build_inverted_index*
|
|
658
|
+g:gutentags_cscope_build_inverted_index
|
|
659
|
+ If set to 1, Gutentags will make `cscope` build an
|
|
660
|
+ inverted index.
|
|
661
|
+ Defaults to 0.
|
|
662
|
+
|
|
663
|
+
|
|
664
|
+The following settings are valid for the `gtags_cscope` module.
|
|
665
|
+
|
|
666
|
+ *gutentags_gtags_executable*
|
|
667
|
+g:gutentags_gtags_executable
|
|
668
|
+ Specifies the name or path of the `gtags` executable
|
|
669
|
+ to use to generate the code database.
|
|
670
|
+ Defaults to `"gtags"`.
|
|
671
|
+
|
|
672
|
+ *gutentags_gtags_cscope_executable*
|
|
673
|
+g:gutentags_gtags_cscope_executable
|
|
674
|
+ Specifies the name or path of the `gtags-cscope`
|
|
675
|
+ executable to use to generate the code database.
|
|
676
|
+ Defaults to `"gtags-cscope"`.
|
|
677
|
+
|
|
678
|
+ *gutentags_gtags_dbpath*
|
|
679
|
+g:gutentags_gtags_dbpath
|
|
680
|
+ Path from the cache directory (|gutentags_cache_dir|
|
|
681
|
+ or project root) to the folder containing the
|
|
682
|
+ definition database file (usually called `GTAGS`).
|
|
683
|
+ Defaults to `""`.
|
|
684
|
+
|
|
685
|
+ *gutentags_gtags_options_file*
|
|
686
|
+g:gutentags_gtags_options_file
|
|
687
|
+ The name of a file that will be looked for in
|
|
688
|
+ a project root directory. The file is expected to
|
|
689
|
+ contain `gtags` options (one per line).
|
|
690
|
+ Defaults to `".gutgtags"`.
|
|
691
|
+
|
|
692
|
+ *gutentags_auto_add_gtags_cscope*
|
|
693
|
+g:gutentags_auto_add_gtags_cscope
|
|
694
|
+ If set to 1, Gutentags will automatically add the
|
|
695
|
+ generated code database to Vim by running `:cs add`
|
|
696
|
+ (see |:cscope|).
|
|
697
|
+ Defaults to 1.
|
|
698
|
+
|
|
699
|
+People using `cscope` or `gtags_cscope` across multiple projects in the same
|
|
700
|
+Vim instance might be interested in the `gutentags_plus` plugin, which handles
|
|
701
|
+switching databases automatically before performing a query.
|
|
702
|
+See https://github.com/skywind3000/gutentags_plus.
|
|
703
|
+
|
|
704
|
+=============================================================================
|
|
705
|
+5. Project Settings *gutentags-project-settings*
|
|
706
|
+
|
|
707
|
+Gutentags can be customized to some extent on a per-project basis with the
|
|
708
|
+following files present in the project root directory:
|
|
709
|
+
|
|
710
|
+ *gutentags-.gutctags*
|
|
711
|
+`.gutctags`: if this file exists, Ctags will be told to load additional
|
|
712
|
+command-line parameters by reading it line by line (see the Ctags
|
|
713
|
+documentation for more information).
|
|
714
|
+
|
|
715
|
+Note that for complex reasons, Gutentags can't run `ctags` from the project
|
|
716
|
+root if you're using |gutentags_cache_dir|, so if the `.gutctags` file exists,
|
|
717
|
+it will be pre-processed in order to make all `--exclude=` clauses into
|
|
718
|
+absolute paths (by prepending the project root). The resulting file will be
|
|
719
|
+saved into the cache directory, and passed to `ctags` via the `--options=`
|
|
720
|
+parameter. If you're _not_ using |gutentags_cache_dir|, the `.gutctags` file
|
|
721
|
+is _not_ pre-processed, and is passed as-is via the `--options=` parameter.
|
|
722
|
+
|
|
723
|
+ *gutentags-.notags*
|
|
724
|
+`.notags`: if this file exists, Gutentags will be disabled completely for that
|
|
725
|
+project.
|
|
726
|
+
|
|
727
|
+
|
|
728
|
+ vim:tw=78:et:ft=help:norl:
|