vim-gutentags

vim-gutentags copied to clipboard

Describe the bug No commands related to this plugin are working when installed with vim-plug. I can see :help gutentags working. Autocompleting with ":Gu<Tab>" doesn't give me any commands. :GutentagsUpdate gives the above error. I also tried reinstalling by removing Plug ... from vimrc, PlugClean and put it back followed by PlugInstall.

Steps to reproduce

1. Add Plug 'ludovicchabant/vim-gutentags' in vimrc.
2. Open a c++ file within a git repo, which also has a tags file generated from ctags -R * at the root of project.
3. Do PlugInstall and see gutentags being installed.
4. Do ":GutentagsUpdate" in vim.

Share your setup

• What OS and version of Vim are you using? OS

$ cat /etc/centos-release
CentOS release 6.10 (Final)

vim

vim --version
Create new file --version? [y] y
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 22 2020 11:24:16)
Included patches: 1-299
Compiled by [email protected]
Huge version without GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_old_static
+arabic            +file_in_path      +mouse_urxvt       -tag_any_white
+autocmd           +find_in_path      +mouse_xterm       -tcl
+autochdir         +float             +multi_byte        +termguicolors
-autoservername    +folding           +multi_lang        +terminal
-balloon_eval      -footer            -mzscheme          +terminfo
+balloon_eval_term +fork()            +netbeans_intg     +termresponse
-browse            +gettext           +num64             +textobjects
++builtin_terms    -hangul_input      +packages          +textprop
+byte_offset       +iconv             +path_extra        +timers
+channel           +insert_expand     +perl              +title
+cindent           +job               +persistent_undo   -toolbar
-clientserver      +jumplist          +popupwin          +user_commands
-clipboard         +keymap            +postscript        +vartabs
+cmdline_compl     +lambda            +printer           +vertsplit
+cmdline_hist      +langmap           +profile           +virtualedit
+cmdline_info      +libcall           -python            +visual
+comments          +linebreak         +python3           +visualextra
+conceal           +lispindent        +quickfix          +viminfo
+cryptv            +listcmds          +reltime           +vreplace
+cscope            +localmap          +rightleft         +wildignore
+cursorbind        -lua               +ruby              +wildmenu
+cursorshape       +menu              +scrollbind        +windows
+dialog_con        +mksession         +signs             +writebackup
+diff              +modify_fname      +smartindent       -X11
+digraphs          +mouse             -sound             -xfontset
-dnd               -mouseshape        +spell             -xim
-ebcdic            +mouse_dec         +startuptime       -xpm
+emacs_tags        -mouse_gpm         +statusline        -xsmp
+eval              -mouse_jsbterm     -sun_workshop      -xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
 f-b for $VIMRUNTIME: "/usr/local/share/vim/vim82"
Compilation: gcc -std=gnu99 -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -std=gnu99   -L. -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE   -L/usr/local/lib -Wl,--as-needed -o vim        -lm -ltinfo -lnsl  -lselinux    -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE  -fstack-protector  -L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc  -L/usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu -lpython3.6m -lpthread -ldl -lutil -lrt -lm  -Wl,-rpath,/home/nikhil-mundra/.rvm/rubies/ruby-2.6.3/lib -L/home/nikhil-mundra/.rvm/rubies/ruby-2.6.3/lib -lruby -lm

• What version of ctags, gtags, or whatever do you have installed?

$ ctags --version
Universal Ctags 5.9.0(89159388), Copyright (C) 2015 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Jan 12 2021, 14:08:32
  URL: https://ctags.io/
  Optional compiled features: +wildcards, +regex, +iconv, +option-directory, +packcc

• Are you using g:gutentags_cache_dir? Yes. This is in the vimrc

let g:gutentags_add_default_project_roots = 0
let g:gutentags_project_root = ['tags', '.git']
let g:gutentags_generate_on_new = 1
let g:gutentags_generate_on_missing = 1
let g:gutentags_generate_on_write = 1
let g:gutentags_generate_on_empty_buffer = 0
let g:gutentags_cache_dir = expand('~/.cache/vim/ctags/')

Post the logs

• Run :let g:gutentags_trace = 1.
• Reproduce the bug.
• Run :messages and show the messages that Gutentags posted.
• Look for the tags.log file that Gutentags' script left behind, and post its contents. Result of :messages:

Messages maintainer: Bram Moolenaar <[email protected]>
"s3_adapter.h" 211L, 6833C
E492: Not an editor command: GutentagsUpdate
Press ENTER or type command to continue

Can't find any file named tags.log.

Additional context Have .ctagsignore at the root of project:

$ cat .ctagsignore
.git
build
builds
views

Same issue here

meet same issue . OS: Ubuntu 18.04 vim version:

NVIM v0.5.0-dev+1157-g0ab88c2ea
Build type: Release
LuaJIT 2.1.0-beta3

Ctags version:

Universal Ctags 5.9.0(p5.9.20201206.0), Copyright (C) 2015 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Dec  6 2020, 06:24:14
  URL: https://ctags.io/
  Optional compiled features: +wildcards, +regex, +iconv, +option-directory, +xpath, +json, +interactive, +yaml, +packcc

gtags version

gtags (GNU GLOBAL) 6.6.5
Powered by Berkeley DB 1.85.
Copyright (c) 1996-2019 Tama Communications Corporation
License GPLv3+: GNU GPL version 3 or later <http://www.gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I tried load Gutentags only ,it still no gutentags command can used...but when I try load in my vim 8.2 ,It can work

Same issue here... anyone figured out what may be wrong?

Same issue here... anyone figured out what may be wrong?

Same issue in WSL, windows 10. It has a simple way to correct it.

Plz find the gutentags.vim in the autoload/ and plugin/, and convert them into unix format

dos2unix autoload/gutentags.vim
dos2unix plugin/gutentags.vim

It will be ok.

Upgraded centos. Also there in CentOS Linux release 7.9.2009 (Core).

tl;dr: call gutentags#rescan() or call gutentags#setup_gutentags() are workarounds for the current buffer. :GutentagsUpdate will be defined after calling one of those, but I think it may be redundant to use that afterwards.

:GutentagsUpdate isn't defined in plugin/gutentags.vim, it is defined in an autoload function gutentags#setup_gutentags() which is called on certain events as defined in plugin/gutentags.vim.

My understanding is that Vim events (autocommand-events) have changed through through versions, so my guess is that such a change possibly led to this issue with :GutentagsUpdate not being defined on VimEnter. At a glance I don't understand the logic behind <amatch>=='' on VimEnter (blame indicates this goes way back to the initial commit).

Sorry the delays.... so, the original repro steps include the important order of (1) opening a code file while gutentags is not installed, and (2) installing gutentags.

Gutentags does its setup when you open a file, because each file could be in a different project, or in no project at all. It would be equally valid to have gutentags commands always defined, and lazily-setup the local buffer information if it's missing. We could certainly refactor the plugin to use that model instead. I frankly can't remember what I was thinking at the time -- I probably just copied the design of some popular plugin of the time... who knows.

Anyway, the quick workaround is to reload the file using :e! and gutentags will be aware of it.

Been a while since I worked on this but here is a patch consisting of what I changed to plugin/gutentags.vim:

diff --git a/plugin/gutentags.vim b/plugin/gutentags.vim
index 63be66b..d2ebffb 100644
--- a/plugin/gutentags.vim
+++ b/plugin/gutentags.vim
@@ -98,11 +98,16 @@ let g:__gutentags_vim_is_leaving = 0
 augroup gutentags_detect
     autocmd!
     autocmd BufNewFile,BufReadPost *  call gutentags#setup_gutentags()
-    autocmd VimEnter               *  if expand('<amatch>')==''|call gutentags#setup_gutentags()|endif
+    autocmd VimEnter               *  call gutentags#setup_gutentags()
     autocmd VimLeavePre            *  call gutentags#on_vim_leave_pre()
     autocmd VimLeave               *  call gutentags#on_vim_leave()
 augroup end
 
+" If vim-gutentags lazy-loaded:
+if v:vim_did_enter
+    call gutentags#setup_gutentags()
+endif
+
 " }}}
 
 " Toggles and Miscellaneous Commands {{{

Don't know if that's an acceptable solution, I don't think I thought through it too much. lazy-loaded in the comment above means if vim-gutentags was lazy-loaded by the plugin manager, like vim-plug or dein with e.g. dein#add('ludovicchabant/vim-gutentags', {'on_ft': ['cs', 'cpp']}), as VimEnter had already been triggered and wouldn't be triggered again.

IIRC I think when I just opened vim with vim in the project root, then used nerdtree to open a file within that project, vim-gutentags wouldn't trigger and :GutentagsUpdate wasn't defined either.