gutentags.txt (37902B)
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 - `pycscope`: generates a code database file using 318 `pycscope`. 319 320 - `gtags_cscope`: same as `cscope` but uses GNU's 321 `gtags` executable and database. 322 323 Defaults to `[ctags]`. 324 325 *gutentags_project_root* 326 g:gutentags_project_root 327 When a buffer is loaded, Gutentags will figure out if 328 it's part of a project that should have tags managed 329 automatically. To do this, it looks for "root markers" 330 in the current file's directory and its parent 331 directories. If it finds any of those markers, 332 Gutentags will be enabled for the project, and a tags 333 file named after |gutentags_ctags_tagfile| will be 334 created at the project root. 335 Defaults to `[]` (an empty |List|). 336 A list of default markers will be appended to the 337 user-defined ones unless 338 |gutentags_add_default_project_roots| is set to 0. 339 340 *gutentags_add_default_project_roots* 341 g:gutentags_add_default_project_roots 342 Defines whether Gutentags should always define some 343 default project roots (see |gutentags_project_root|). 344 This can be useful to prevent unnecessary disk access 345 when Gutentags searches for a project root. 346 The default markers are: 347 `['.git', '.hg', '.svn', '.bzr', '_darcs', '_darcs', '_FOSSIL_', '.fslckout']` 348 349 *gutentags_add_ctrlp_root_markers* 350 g:gutentags_add_ctrlp_root_markers 351 If Gutentags finds `g:ctrlp_root_markers` (used by the 352 CtrlP plugin), it will append those root markers to 353 the existing ones (see |g:gutentags_project_root|). 354 Set this to 0 to stop it from happening. 355 Defaults to 1. 356 357 *gutentags_exclude_filetypes* 358 g:gutentags_exclude_filetypes 359 A |List| of file types (see |'filetype'|) that Gutentags 360 should ignore. When a buffer is opened, if its 361 'filetype' is found in this list, Gutentags features 362 won't be available for this buffer. 363 Defaults to an empty list (`[]`). 364 365 *gutentags_exclude_project_root* 366 g:gutentags_exclude_project_root 367 A list of project roots to generally ignore. If a file 368 is opened inside one of those projects, Gutentags 369 won't be activated. This is similar to placing 370 a `.notags` file in the root of those projects, but 371 can be useful when you don't want to, or can't, place 372 such a file there. 373 Defaults to `['/usr/local', '/opt/homebrew', '/home/linuxbrew/.linuxbrew']`, 374 which are the folders where Homebrew is known to 375 create a Git repository by default. 376 377 *gutentags_project_root_finder* 378 g:gutentags_project_root_finder 379 When a buffer is loaded, Gutentags uses a default 380 (internal) implementation to find that file's 381 project's root directory, using settings like 382 |g:gutentags_project_root|. When you specify 383 |g:gutentags_project_root_finder|, you can tell 384 Gutentags to use a custom implementation, such as 385 `vim-projectroot`. The value of this setting must be 386 the name of a function that takes a single string 387 argument (the path to the current buffer's file) and 388 returns a string value (the project's root directory). 389 Defaults to `''`. 390 Note: when set, the called implementation will 391 possibly ignore |g:gutentags_project_root|. 392 Note: an implementation can fallback to the default 393 behaviour by calling 394 `gutentags#default_get_project_root`. 395 396 *gutentags_generate_on_missing* 397 g:gutentags_generate_on_missing 398 If set to 1, Gutentags will start generating an initial 399 tag file if a file is open in a project where no tags 400 file is found. See |gutentags_project_root| for how 401 Gutentags locates the project. 402 When set to 0, Gutentags will only generate the first 403 time the file is saved (if 404 |gutentags_generate_on_write| is set to 1), or when 405 |GutentagsUpdate| or |GutentagsGenerate| is run. 406 Defaults to 1. 407 408 *gutentags_generate_on_new* 409 g:gutentags_generate_on_new 410 If set to 1, Gutentags will start generating the tag 411 file when a new project is open. A new project is 412 considered open when a buffer is created for a file 413 whose corresponding tag file has not been "seen" yet 414 in the current Vim session -- which pretty much means 415 when you open the first file in a given source control 416 repository. 417 When set to 0, Gutentags won't do anything special. 418 See also |gutentags_generate_on_missing| and 419 |gutentags_generate_on_write|. 420 Defaults to 1. 421 422 *gutentags_generate_on_write* 423 g:gutentags_generate_on_write 424 If set to 1, Gutentags will update the current 425 project's tag file when a file inside that project is 426 saved. See |gutentags_project_root| for how Gutentags 427 locates the project. 428 When set to 0, Gutentags won't do anything on save. 429 This means that the project's tag file won't reflect 430 the latest changes, and you will have to run 431 |GutentagsUpdate| manually. 432 Defaults to 1. 433 434 *gutentags_generate_on_empty_buffer* 435 g:gutentags_generate_on_empty_buffer 436 If set to 1, Gutentags will start generating the tag 437 file even if there's no buffer currently open, as long 438 as the current working directory (as returned by 439 |:cd|) is inside a known project. 440 This is useful if you want Gutentags to generate the 441 tag file right after opening Vim. 442 Defaults to 0. 443 444 *gutentags_background_update* 445 g:gutentags_background_update 446 Specifies whether the process that updates the tags 447 file should be run in the background or in the 448 foreground. If run in the foreground, Vim will block 449 until the process is complete. 450 Defaults to 1. 451 452 *gutentags_cache_dir* 453 g:gutentags_cache_dir 454 Specifies a directory in which to create all the tags 455 files, instead of writing them at the root of each 456 project. This is handy to keep tags files from 457 polluting many directories all across your computer. 458 459 *gutentags_resolve_symlinks* 460 g:gutentags_resolve_symlinks 461 When set to 1, Gutentags will resolve any symlinks in 462 the current buffer's path in order to find the project 463 it belongs to. This is what you want if you're editing 464 a symlink located outside of the project, and it 465 points to a file inside the project. However, this is 466 maybe not what you want if the symlink itself is 467 part of the project. 468 Defaults to 0. 469 470 *gutentags_init_user_func* 471 g:gutentags_init_user_func 472 When set to a non-empty string, it is expected to be 473 the name of a function that will be called when a file 474 is opened in a project. The function gets passed the 475 path of the file and if it returns 0, Gutentags won't 476 be enabled for that file. 477 478 You can use this to manually set buffer-local 479 settings: 480 481 * `b:gutentags_ctags_tagfile` (see |gutentags_ctags_tagfile|). 482 483 This setting was previously called 484 `gutentags_enabled_user_func`. The old setting is 485 still used as a fallback. 486 487 Defaults to "". 488 489 *gutentags_define_advanced_commands* 490 g:gutentags_define_advanced_commands 491 Defines some advanced commands like 492 |GutentagsToggleEnabled| and |GutentagsUnlock|. 493 494 *gutentags_project_info* 495 g:gutentags_project_info 496 Defines ways for Gutentags to figure out what kind of 497 project any given file belongs to. This should be 498 a list of dictionaries: 499 500 let g:gutentags_project_info = [] 501 call add(g:gutentags_project_info, {...}) 502 503 Each dictionary item must contain at least a `type` 504 key, indicating the type of project: 505 506 {"type": "python"} 507 508 Other items will be used to figure out if a project is 509 of the given type. 510 511 "file": any existing file with this path (relative to 512 the project root) will make the current project match 513 the given info. 514 515 "glob": any result found with this glob pattern 516 (relative to the project root) will make the current 517 project match the given info. See |glob()| for more 518 information. 519 520 Gutentags adds by default the following definitions: 521 522 call add(g:gutentags_project_info, {'type': 'python', 'file': 'setup.py'}) 523 call add(g:gutentags_project_info, {'type': 'ruby', 'file': 'Gemfile'}) 524 525 This means, for example, that you can use 526 `g:gutentags_ctags_executable_ruby` out of the box. 527 See |gutentags_ctags_executable_{filetype}| for more 528 information. 529 530 *gutentags_file_list_command* 531 g:gutentags_file_list_command 532 Specifies command(s) to use to list files for which 533 tags should be generated, instead of recursively 534 examining all files within the project root. When 535 invoked, file list commands will execute in the 536 project root directory. 537 538 This setting is useful in projects using source 539 control to restrict tag generation to only files 540 tracked in the repository. 541 542 This variable may be set in one of two ways. If 543 set as a |String|, the specified command will be used to 544 list files for all projects. For example: > 545 546 let g:gutentags_file_list_command = 'find . -type f' 547 < 548 If set as a |Dictionary|, this variable should be set 549 as a mapping of project root markers to the desired 550 file list command for that root marker. (See 551 |gutentags_project_root| for how Gutentags uses root 552 markers to locate the project.) For example: > 553 554 let g:gutentags_file_list_command = { 555 \ 'markers': { 556 \ '.git': 'git ls-files', 557 \ '.hg': 'hg files', 558 \ }, 559 \ } 560 < 561 Note: If a custom ctags executable is specified, it 562 must support the '-L' command line option in order to 563 read the list of files to be examined. 564 565 566 The following settings are valid for the `ctags` module. 567 568 *gutentags_ctags_executable* 569 g:gutentags_ctags_executable 570 Specifies the ctags executable to launch. 571 Defaults to `ctags`. 572 573 *gutentags_ctags_executable_{filetype}* 574 g:gutentags_ctags_executable_{type} 575 Specifies the ctags executable to launch for a project 576 of type {type}. See |gutentags_project_info| for more 577 information. 578 IMPORTANT: please see |gutentags-ctags-requirements|. 579 Example: > 580 let g:gutentags_ctags_executable_ruby = 'ripper-tags' 581 < 582 583 *gutentags_ctags_tagfile* 584 g:gutentags_ctags_tagfile 585 Specifies the name of the tag file to create. This 586 will be appended to the project's root. See 587 |gutentags_project_root| for how Gutentags locates the 588 project. 589 Defaults to `tags`. 590 591 *gutentags_ctags_exclude* 592 g:gutentags_ctags_exclude 593 A list of file patterns to pass to the 594 |gutentags_ctags_executable| so that they will be 595 excluded from parsing for the tags generation. 596 See also |gutentags_ctags_exclude_wildignore|. 597 Defaults to `[]` (an empty |List|). 598 599 *gutentags_ctags_exclude_wildignore* 600 g:gutentags_ctags_exclude_wildignore 601 When 1, Gutentags will automatically pass your 602 'wildignore' file patterns to the 603 |gutentags_ctags_executable| so that they are ignored. 604 Set also |gutentags_ctags_exclude| to pass custom 605 patterns. 606 Defaults to 1. 607 608 *gutentags_ctags_auto_set_tags* 609 g:gutentags_ctags_auto_set_tags 610 If set to 1, Gutentags will automatically prepend 611 'tags' with the exact path to the tag file for the 612 current project. See |gutentags_project_root| for how 613 Gutentags locates the project. 614 When set to 0, Gutentags doesn't change 'tags', and 615 this means that whatever tag file it generates may 616 not be picked up by Vim. See |tagfiles()| to know what 617 tag files Vim knows about. 618 Defaults to 1. 619 620 *gutentags_ctags_extra_args* 621 g:gutentags_ctags_extra_args 622 A list of arguments to pass to `ctags`. 623 Defaults to `[]`. 624 625 *gutentags_ctags_post_process_cmd* 626 g:gutentags_ctags_post_process_cmd 627 If defined, the tags generation script will run the 628 command with an argument that points to a temporary 629 copy of the tags file. If the post-process step is 630 modifying the tags file, it needs to do so in-place. 631 This is useful for cleaning up a tags file that may 632 contain tags with non-ASCII names that somehow upsets 633 Vim. 634 Defaults to `""` (an empty |String|). 635 636 637 The following settings are valid for the `cscope` module. 638 639 *gutentags_cscope_executable* 640 g:gutentags_cscope_executable 641 Specifies the name or path of the `cscope` executable 642 to use to generate the code database. 643 Defaults to `"cscope"`. 644 645 *gutentags_scopefile* 646 g:gutentags_scopefile 647 Specifies the name of the scope file to create. This 648 will be appended to the project's root. See 649 |gutentags_project_root| for how Gutentags locates the 650 project. 651 Defaults to `"cscope.out"`. 652 653 *gutentags_auto_add_cscope* 654 g:gutentags_auto_add_cscope 655 If set to 1, Gutentags will automatically add the 656 generated code database to Vim by running `:cs add` 657 (see |:cscope|). 658 Defaults to 1. 659 660 *gutentags_cscope_build_inverted_index* 661 g:gutentags_cscope_build_inverted_index 662 If set to 1, Gutentags will make `cscope` build an 663 inverted index. 664 Defaults to 0. 665 666 667 The following settings are valid for the `pycscope` module. 668 669 *gutentags_pycscope_executable* 670 g:gutentags_pycscope_executable 671 Specifies the name or path of the `pycscope` executable 672 to use to generate the code database. 673 Defaults to `"pycscope"`. 674 675 *gutentags_auto_add_pycscope* 676 g:gutentags_auto_add_pycscope 677 If set to 1, Gutentags will automatically add the 678 generated code database to Vim by running `:cs add` 679 (see |:pycscope|). 680 Defaults to 1. 681 682 683 The following settings are valid for the `gtags_cscope` module. 684 685 *gutentags_gtags_executable* 686 g:gutentags_gtags_executable 687 Specifies the name or path of the `gtags` executable 688 to use to generate the code database. 689 Defaults to `"gtags"`. 690 691 *gutentags_gtags_cscope_executable* 692 g:gutentags_gtags_cscope_executable 693 Specifies the name or path of the `gtags-cscope` 694 executable to use to generate the code database. 695 Defaults to `"gtags-cscope"`. 696 697 *gutentags_gtags_dbpath* 698 g:gutentags_gtags_dbpath 699 Path from the cache directory (|gutentags_cache_dir| 700 or project root) to the folder containing the 701 definition database file (usually called `GTAGS`). 702 Defaults to `""`. 703 704 *gutentags_gtags_options_file* 705 g:gutentags_gtags_options_file 706 The name of a file that will be looked for in 707 a project root directory. The file is expected to 708 contain `gtags` options (one per line). 709 Defaults to `".gutgtags"`. 710 711 *gutentags_auto_add_gtags_cscope* 712 g:gutentags_auto_add_gtags_cscope 713 If set to 1, Gutentags will automatically add the 714 generated code database to Vim by running `:cs add` 715 (see |:cscope|). 716 Defaults to 1. 717 718 719 People using `cscope`, `pycscope` or `gtags_cscope` across multiple projects in the same 720 Vim instance might be interested in the `gutentags_plus` plugin, which handles 721 switching databases automatically before performing a query. 722 See https://github.com/skywind3000/gutentags_plus. 723 724 ============================================================================= 725 5. Project Settings *gutentags-project-settings* 726 727 Gutentags can be customized to some extent on a per-project basis with the 728 following files present in the project root directory: 729 730 *gutentags-.gutctags* 731 `.gutctags`: if this file exists, Ctags will be told to load additional 732 command-line parameters by reading it line by line (see the Ctags 733 documentation for more information). 734 735 Note that for complex reasons, Gutentags can't run `ctags` from the project 736 root if you're using |gutentags_cache_dir|, so if the `.gutctags` file exists, 737 it will be pre-processed in order to make all `--exclude=` clauses into 738 absolute paths (by prepending the project root). The resulting file will be 739 saved into the cache directory, and passed to `ctags` via the `--options=` 740 parameter. If you're _not_ using |gutentags_cache_dir|, the `.gutctags` file 741 is _not_ pre-processed, and is passed as-is via the `--options=` parameter. 742 743 *gutentags-.notags* 744 `.notags`: if this file exists, Gutentags will be disabled completely for that 745 project. 746 747 748 vim:tw=78:et:ft=help:norl: