E492: Not an editor command: GutentagsUpdate
subtleseeker opened this issue · 8 comments
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" 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
- Add
Plug 'ludovicchabant/vim-gutentags'
in vimrc. - Open a c++ file within a git repo, which also has a tags file generated from
ctags -R *
at the root of project. - Do
PlugInstall
and see gutentags being installed. - 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 nikhil-mundra@nikhil-mundra.dev.nutanix.com
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 <Bram@vim.org>
"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.