ludovicchabant / vim-gutentags Goto Github PK
View Code? Open in Web Editor NEWA Vim plugin that manages your tag files
Home Page: https://bolt80.com/gutentags/
License: MIT License
A Vim plugin that manages your tag files
Home Page: https://bolt80.com/gutentags/
License: MIT License
I somehow got ctags/vim-autotags to start running on /usr/local/ covering my homebrew installation and got OSX to throw up an "almost out of diskspace message"
$ ls -lah tags*
-rw-r--r-- 1 mbehrens wheel 6 Sep 1 21:37 tags.lock
-rw-r--r-- 1 mbehrens wheel 37G Sep 1 23:05 tags.temp
Anyway to add an autokill timeout? Like autokill ctags after it has been running for 60s or some configurable amount? Since autotags just runs in the background and I leave vim open 24/7, it's hard to see when an error like this error occurs.
System info:
IM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 10 2014 22:34:51)
MacOS X (unix) version
Included patches: 1-383
Compiled by Homebrew
Huge version with MacVim GUI. Features included (+) or not (-):
+acl +clipboard +cursorshape +extra_search -gettext +lispindent +mouse_dec +multi_lang +profile +smartindent +tcl +virtualedit -X11
+arabic +cmdline_compl +dialog_con_gui +farsi -hangul_input +listcmds -mouse_gpm -mzscheme +python -sniff +terminfo +visual -xfontset
+autocmd +cmdline_hist +diff +file_in_path +iconv +localmap -mouse_jsbterm +netbeans_intg -python3 +startuptime +termresponse +visualextra +xim
+balloon_eval +cmdline_info +digraphs +find_in_path +insert_expand -lua +mouse_netterm +odbeditor +quickfix +statusline +textobjects +viminfo -xsmp
+browse +comments +dnd +float +jumplist +menu +mouse_sgr +path_extra +reltime -sun_workshop +title +vreplace -xterm_clipboard
++builtin_terms +conceal -ebcdic +folding +keymap +mksession -mouse_sysmouse +perl +rightleft +syntax +toolbar +wildignore -xterm_save
+byte_offset +cryptv +emacs_tags -footer +langmap +modify_fname +mouse_urxvt +persistent_undo +ruby +tag_binary +transparency +wildmenu -xpm
+cindent +cscope +eval +fork() +libcall +mouse +mouse_xterm +postscript +scrollbind +tag_old_static +user_commands +windows
+clientserver +cursorbind +ex_extra +fullscreen +linebreak +mouseshape +multi_byte +printer +signs -tag_any_white +vertsplit +writebackup
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "/.vim/vimrc"/.vim/gvimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe -DMACOS_X_UNIX -F/usr/local/Cellar/python/2.7.8/Frameworks -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/System/Library/Frameworks/Tcl
.framework/Headers -D_REENTRANT=1 -D_THREAD_SAFE=1 -D_DARWIN_C_SOURCE=1
Linking: clang -L. -L/usr/local/lib -L. -L/usr/local/lib -L/usr/local/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -F/usr/local/Cellar/python/2.7.8/Frameworks -L/usr/local/lib -o Vim -framework Coc
oa -framework Carbon -lm -lncurses -liconv -framework Cocoa -fstack-protector -L/usr/local/lib -L/System/Library/Perl/5.16/darwin-thread-multi-2level/CORE -lperl -framework Python -F/System/Library/Frameworks -framework Tcl -
framework CoreFoundation -framework Ruby
Today I noticed nearly all the folders in my vim-plug handled bundle/ folder contained a 'tags' file, which I later discovered gets created when I browse the :help file provided by the plugin.
It's not a major issue but it'd be nice if it didn't do so.
When starting vim in a directory that is not under any VCS, it gives me
Error detected while processing function gutentags#setup_gutentags[35]..<SNR>113_cache_project_root:
line 17:
E713: Cannot use empty key for Dictionary
It, quite obviously, started happening after the 52a1f72 commit.
YouCompleteMe can autocomplete from tags files, but the tags file needs to be generated with --fields=+l.
The following patch seems to work ok (in my limited testing!). Have you considered adding this flag?
diff --git a/plat/unix/update_tags.sh b/plat/unix/update_tags.sh
index a4366e4..18ddbfd 100755
--- a/plat/unix/update_tags.sh
+++ b/plat/unix/update_tags.sh
@@ -80,7 +80,7 @@ fi
echo "Running ctags"
echo "$CTAGS_EXE -f \"$TAGS_FILE.temp\" $CTAGS_ARGS \"$PROJECT_ROOT\""
-$CTAGS_EXE -f "$TAGS_FILE.temp" $CTAGS_ARGS "$PROJECT_ROOT"
+$CTAGS_EXE -f "$TAGS_FILE.temp" $CTAGS_ARGS "$PROJECT_ROOT" --fields=+l
echo "Replacing tags file"
echo "mv -f \"$TAGS_FILE.temp\" \"$TAGS_FILE\""
I have so many git repositories including HOME directory.
I hope it supports some option which is enable only for some repos, but disabled all other repos (inverse of .notags?).
For example,
let g:gutentags_use_global_enable_dotfile = '.gutentags-enable'
If user set such a variable, only enabled for a repo which contains such file.
Or only enable if 'tags' file already exists. Maybe 'gutentags_only_update_mode'-like option?
My default shell is tcsh and this is causing issues when using gutentags, raising the following error when opening Vim or manually running GutentagsUpdate - Ambiguous output redirect.
This is due to using the 2>&1
redirect within autoload/gutentags/ctags.vim
It would be nice if you can support GNU Global or Cscope as I find ctags inadequate for large code bases.
Good work.
hello, i am using set autochdir in my vimrc and i find that i have to expand the current file to an absolute path before calling gutentags#get_project_root. i am submitting a pull request that illustrates my work around in case that is found to be satisfactory (as well as for illustration purposes)
Fixed in blueyed@9ef876f (based on / included in #72).
btw: here is a integration branch with all my recent PRs: master...blueyed:integration
Hi,
I was so happy reading your documentation!
Installed with Vundle.
I did a simple test (running on os x with vim terminal)
mkdir foo
cd foo
git init
touch classA.php classB.php
classA extends classB
git add .
git commit -m "test"
ls -lah
I see a tags.lock
Nothing more!
:GutentagsGenerate tags
Displays "The tags file is already being updated, please try again later"
It's a fail.
Did I miss something?
When in some Git submodule, I would rather use the existing tags
file from the main repo (up in the directory) tree, than create a new tags file for this project.
A naive approach for this is the following, but will cause many more disk accesses.
Therefore a separate option (enabled by default) might make sense.
Also, having a fixed list of markers really causes unnecessary disk accesses, even if you only want to use ['tags', '.git']
! (see #75)
index 4c859b2..04da0e0 100644
--- i/autoload/gutentags.vim
+++ w/autoload/gutentags.vim
@@ -81,14 +81,14 @@ endfunction
" Finds the first directory with a project marker by walking up from the given
" file path.
function! gutentags#get_project_root(path) abort
- let l:path = gutentags#stripslash(a:path)
- let l:previous_path = ""
let l:markers = g:gutentags_project_root[:]
if exists('g:ctrlp_root_markers')
let l:markers += g:ctrlp_root_markers
endif
- while l:path != l:previous_path
- for root in l:markers
+ for root in l:markers
+ let l:path = gutentags#stripslash(a:path)
+ let l:previous_path = ""
+ while l:path != l:previous_path
if getftype(l:path . '/' . root) != ""
let l:proj_dir = simplify(fnamemodify(l:path, ':p'))
let l:proj_dir = gutentags#stripslash(l:proj_dir)
@@ -102,10 +102,10 @@ function! gutentags#get_project_root(path) abort
endif
return l:proj_dir
endif
- endfor
- let l:previous_path = l:path
- let l:path = fnamemodify(l:path, ':h')
- endwhile
+ let l:previous_path = l:path
+ let l:path = fnamemodify(l:path, ':h')
+ endwhile
+ endfor
call gutentags#throw("Can't figure out what tag file to use for: " . a:path)
endfunction
diff --git i/plugin/gutentags.vim w/plugin/gutentags.vim
index 3f756b9..d29cfcf 100644
--- i/plugin/gutentags.vim
+++ w/plugin/gutentags.vim
@@ -50,7 +50,7 @@ if !exists('g:gutentags_modules')
endif
if !exists('g:gutentags_project_root')
- let g:gutentags_project_root = []
+ let g:gutentags_project_root = ['tags']
endif
let g:gutentags_project_root += ['.git', '.hg', '.svn', '.bzr', '_darcs', '_FOSSIL_', '.fslckout']
What do you think?
This is perhaps more of a question than an issue, but I just can't find any way to disable tags regeneration when opening Vim to edit a git commit message. As I typically commit soon after making some changes (in an existing long-running Vim instance), this almost invariably results in an annoying (especially because it's too long and so has to be dismissed) message from gutentags about the tag file being already updated when it tries to update it in the new Vim instance too.
I tried putting let g:gutentags_enabled=0
in ~/vim/ftplugin/gitcommit.vim
but this doesn't help as it's already too late by then. Is there some other way to configure the plugin to never generate tags when editing COMMIT_EDITMSG
?
Or, alternatively, maybe it should detect that the generation is already in progress and silently do nothing then?
I have twice been bitten by this. When opening some files from https://github.com/coolwanglu/neovim.as, a file tags.temp is created that (I think) grows for ever. First time it was about 3GB when I deleted I think. This time 1.5GB. I still have it in my trash.
The only project that had the the issue is the one mentioned above. I am on windows7, using ctags5.8
Let me know if I can help troubleshoot this, I had to remove gutentags for now, as my project lives in dropbox, and the huge tags file screws my quota.
Gutentag,
I've just installed gutentags and I get this error:
Error detected while processing function gutentags#setup_gutentags..<SNR>89_update_tags..gutentags#cta
gs#generate:
line 26:
E121: Undefined variable: g:gutentags_options_file
E116: Invalid arguments for function len(g:gutentags_options_file)
E15: Invalid expression: len(g:gutentags_options_file)
Error detected while processing function gutentags#setup_gutentags:
line 45:
E171: Missing :endif
The doc does not mention a g:gutentags_options_file
setting, did I miss something?
Just installed the plugin, and opened up a java file in a project i'm working on. I get this error immediately (before the file loads):
Error detected while processing function 26_setup_gutentags..26_update_tags:
line 74:
E371: Command not found
Error detected while processing function 26_setup_gutentags:
line 42:
E171: Missing :endif
Would be nice to have the status line update itself once the tag file generation is done. And it would not require the lock file.
I have been attempting to get gutentags to work on a PHP codebase, but have problems.
Entering a project correctly generates a ~50MB tags file, jumping through functions and autocompleting using the tags works great. But when I call :GutentagsUpdate
or save a file, the tags file becomes much smaller (around ~6Mb) and Vim complains with E431: Format error in tags file
when I attempt to jump to a function definition again.
After attempting to debug the problem it appears that when plat/unix/update_tags.sh
is called, it attempts to generate a temp tags file, but the $UPDATED_SOURCE
value becomes .../vim-gutentags/plat/unix/update_tags.sh
in the grep command (see https://github.com/ludovicchabant/vim-gutentags/blob/master/plat/unix/update_tags.sh#L77).
This means the temp file is blank and the ctags --append
only populates it with the new content before replacing the old tags file.
Hope this makes sense. Any pointers on how to debug this further? Happy to help out.
Cheers.
Error while generating ctags file:
gutentags: File /Users/gregoryblock/.vim/cache/tags/Users-gregoryblock-radish-bu
ild-admin-tags doesn't appear to be a ctags file. Please delete it and run :Gute
ntagsUpdate!.
Hi, Installed using pathogen. I have run ctags in the project before but this happens even if the tags file is deleted. Generates the tag file fine on startup, but :w
generates the following error:
Error detected while processing function 208_write_triggered_update_tags..208_update_tags:
line 6:
E121: Undefined variable: b:gutentags_files
E15: Invalid expression: b:gutentags_files[a:module]
Just curious if there was a way to handle gem dependency tags in ruby? I'm coming from https://github.com/szw/vim-tags which detects the Gemfile and includes the bundle show --paths
automatically, and don't see a way to do that with gutentags. Is there a way to set that up natively that I'm missing, or would this be more of a feature/pull-request?
Related: #50
I have a project, I have generated a tags file manually with this command:
ctags --exclude='app/public/components/*' app/
now, even if the readme says:
it will partially re-generate the tag file. Every time you save, it will silently, in the background, update the tags for that file.
every time I save a file, the tags file is updated to include every file in the project. since this plugin is supposed to work out of the box I'm not sure what I've done wrong...
I have a ~/.git/
folder for managing dotfiles. I don't want this to trigger gutentags. Is there a way to avoid this, while still enabling gutentags in ~/foo/.git
subdirectories, which doesn't involve me setting up a bunch of autocmds and manually managing g:gutentags_enabled
?
Thanks for this project, I like the choices you have made.
If I work on linux kernel, i generated tags by running 'make tags'.
And I hoped gutentags only updated tags for modified file. But it doesn't.
If I open a source (no change), it starts ctags to generate tags and the geenrated tags includes tags for all the archs.
$ gvim arch/arm/mach-at91/board-x.c
$ ls -l tags*
-rw-r--r-- 1 134663743 Jan 18 15:12 tags
-rw-r--r-- 1 134663743 Jan 18 15:12 tags.bak
-rw-r--r-- 1 5 Jan 18 15:13 tags.lock
-rw-r--r-- 1 283 Jan 18 15:12 tags.log
-rw-r--r-- 1 38368111 Jan 18 15:14 tags.temp
...
$ ls -l tags*
-rw-r--r-- 1 197035344 Jan 18 15:15 tags
-rw-r--r-- 1 134663743 Jan 18 15:12 tags.bak
-rw-r--r-- 1 283 Jan 18 15:12 tags.log
The 'tags.bak' (generated by 'make tags') only includes tags for 'arm' arch (for arch directory).
But re-genrated 'tags' includes tags for all other archs such as mips. alpha, ia64...,
Is it expected? Should I generate .notags and only update tags manually for linux kernel?
Thanks,
Thanks for the great plugin; it works straight out of the box.
One caveat is that when I use the CtrlP plugin to search the tags (with :CtrlPTag
) the results of the search include the tag of the function's definition and the declaration. I never want to see the declaration so that means after every CtrlP search I have to hit "Arrow up" to select the definition tag.
The "taglist.vim" does exactly see this: no declaration tags. Could there be such an option in vim-gutentags (funny name, by the way :)?
I'm working with Object Pascal code, if it's relevant.
With no options set, I get the following error when starting vim and when trying to run GutentagsGenerate
: zsh:1: no matches found: *.o
Running GutentagsGenerate
also messes up the Vim UI, and I have to run redraw!
to fix it
After looking around the code, your blog (http://ludovic.chabant.com/), and project site (http://bolt80.com/gutentags/), I have not been able to determine the license under which you have released the source for Gutentags. Please provide a "LICENSE" or "CONTRIB" file specifying the license and (if applicable) any additional licensing rules which apply to contributions.
It seems like I'm having some kind of similar issue as #7 (although I'm on a Windows 7 using a 64-bit build).
I launch gVim with tracing enabled:
gvim +GutentagsToggleTrace <file>
And then I get the following message (so far, so good):
gutentags: The tags file is already being updated, please try again later.
gutentags: Tracing is enabled.
Whenever I try to save a file, I get this:
gutentags: Tag file 'd:\Git\<project>\tags' is already being updated. Queuing it up...
gutentags:
After a couple of tries a log file appears with the following content:
Locking tags file...
Running ctags
"ctags" -R -f "d:\Git\<project>\tags.temp" --exclude=".git" --exclude=".sass-cache" --exclude="tmp" --exclude=".bundle" --exclude="*.min.*" --exclude="tags" --exclude="node_modules" --exclude="bower_components" --exclude="vendor" --exclude="*.jpg" --exclude="*.png" --exclude="*.svg" --exclude="*.ico" --exclude="*.pdf" --exclude="*.epub" d:\Git\<project>
No tags
file gets generated (and the tags.lock
file is still in the root directory). Any ideas?
For reference, this is my .ctags
file:
--recurse=yes
--tag-relative=yes
--fields=-k
--fields=+K
--exclude=.git
--exclude=node_modules
--exclude=bower_components
--exclude=log
--exclude=tmp
--exclude=dist
--langdef=css
--langmap=css:.css
--langmap=css:+.scss
--langmap=css:+.sass
--langmap=css:+.styl
--langmap=css:+.less
--regex-css=/^[ \t]*(([A-Za-z0-9_-]+[ \t\n,]+)+)\{/\1/t,tag,tags/
--regex-css=/^[ \t]*#([A-Za-z0-9_-]+)/#\1/i,id,ids/
--regex-css=/^[ \t]*\.([A-Za-z0-9_-]+)/.\1/c,class,classes/
Thanks!
I wish I could quit using Windows altogether, but I don't see that happening any time soon. Whoever it was at Microsoft that thought allowing a space or spaces in a path was a good idea, was an idiot.
Anyhow, this doesn't work at all for paths with spaces in them. I've forked this and started working on a fix, but it's not complete yet. I've got as far as getting update_tags.cmd to run fine from the command line, but it doesn't work when called from within Vim. I'll try to get my work in progress posted on GitHub tomorrow, but the easiest way to handle spaces is to quote all parameters before they go to the .cmd file. That means not stripping the quotes from the args in update_tags.cmd and not quoting the variables later after parsing the args.
Also, I could find no way to call "start /b "d:\program files\rest_of_path\update_tags.cmd" without it generating a "d:\program is not a command" error. I tried everything I could think of to escape the spaces without any success. What did seem to work was 'start /b /d "d:\program files\rest_of_path" update_tags.cmd' which is specifying the starting directory separately. It didn't require much in the way of changes, but it still didn't work when vim-gutentags called it in Vim.
Thanks.
Jon Hatfield
here is what i get when opening a file:
"~/Tresors/teaching/Frontiers in Biosciences/tutorial.tex" 356L, 13304C
Error detected while processing function gutentags#setup_gutentags[79]..<SNR>117_update_tags[33]..gutentags#ctags#generate:
line 17:
E344: Can't find directory "/Users/nbecker/Tresors/teaching/Frontiers_in_Biosciences" in cdpath
E472: Command failed
Error detected while processing function gutentags#setup_gutentags:
line 79:
E171: Missing :endif
somehow underscores get inserted?! i have updated vim-gutentags just now, should be the current version. macvim, with vim 7.4.1362
I've been trying to figure out how to get my whole project tagged at once, and I found :GutentagsGenerate
in the help file, so I tried it. However, Vim gave me "E492: Not an editor command: :GutentagsGenerate tags"
I think I should instead use ":GutentagsUpdate!", but it doesn't seem to get everything in my project.
Hey, thanks for the closure that gutentags brought to us Vim taggers.
How about generating the temporary tag files, such as tags.lock
, into ta $XDG_CACHE_HOME/tags
folder ? (If set up by the user.)
While there are good reasons to leave the tag files in the project root, I don't see many for the temporary tag files.
Is there a way to have Gutentags create the cache directory if it doesn't exist?
I am using the following setting, but if the folder doesn't exist then Gutentags throws an error.
let g:gutentags_cache_dir = "~/.dotfiles/vim/vim.symlink/cache/gutentags"
This is the error I get:
Error detected while processing function gutentags#setup_gutentags..<SNR>114_update_tags..gutentags#ctags#generate:
line 5:
E344: Can't find directory "/Users/gblock0/.dotfiles/vim/vim.symlink/cache/gutentags" in cdpath
Press ENTER or type command to continue
Error detected while processing function gutentags#setup_gutentags..<SNR>114_update_tags..gutentags#ctags#generate:
line 5:
E472: Command failed
Press ENTER or type command to continue
Error detected while processing function gutentags#setup_gutentags:
line 54:
E171: Missing :endif
Press ENTER or type command to continue
It seems to be impossible to explicitly pass .ctags
as the extra options file name to ctags under Windows, see the bug report, so just creating a .ctags
file in the project root breaks the tag generation as the plugin detects its presence and passed --options=.ctags
to ctags which then exits with an error.
The especially annoying thing is that it's enough to not specify --options
at all for .ctags
to be found and used, as can be seen with ctags --verbose
, so just removing the lines adding -o
option from ctags.vim
fixes this for me because project and tag files directories are the same in my case. But I don't know what to do in case they are different (but why would they be anyhow?).
Would it be possible or make sense to provide support for other tools that indexes the code.
I'm mainly thinking about cscope which as builtin support in Vim.
But it could be extended to tools like : https://github.com/junkblocker/codesearch
My disk was unexpectedly full, and after a few minutes of deleting old log files and such, realized that it was actually due to a 75gb tags temp file in /usr/local.
I suspect that it was because I opened an nginx config file earlier today, since /etc/nginx
is symlinked to /usr/local/etc/nginx
when installed with homebrew on OS X, and /usr/local contains a .git
directory.
let g:gutentags_generate_on_missing = 0
does not disable automatic tags generation.
let g:gutentags_generate_on_missing = 0
let g:gutentags_generate_on_new = 0
did the trick.
I suppose this is the offender https://github.com/ludovicchabant/vim-gutentags/blob/master/autoload/gutentags.vim#L140 .
What does gutentags_generate_on_new
do? ( #26 ) .
Hi Ludovic,
thanks for the awesome plugin. It works for me without any configuration I've to made and it is very fast.
The following commands are not available:
:GutentagsGenerate
:GutentagsToggleEnabled
:GutentagsToggleTrace
:GutentagsUnlock
Maybe you can update the documentation.
If .vimrc
contains let g:gutentags_enabled = 0
then saving a file in a git repo still makes ctags recreate the tags
file.
If gutentags_project_root
already contains a file named tags
, it will be silently overwritten. If this file isn't tracked by the version control tool yet, this will cause data loss. If this file is already tracked - the version control tool will still be annoying about the content of this file getting changed everytime vim-gutentags overwrites it.
Having any less common default name for the tags file won't completely remove the risk of filename collisions. A better approach is probably to put these files somewhere else, outside gutentags_project_root
, in a temporary directory perhaps?
Hi,
After updating I am getting this error. I tried setting the resolve symlinks to 1 and that didn't seem to work. Any idea what's going on?
Error while generating ctags file:
gutentags: File /Users/gregoryblock/.vim/cache/tags/Users-gregoryblock-stuff-tags doesn't appear to be a ctags file. Please delete it and run :GutentagsUpdate!.
That file does exist and when I delete it the first save works fine, but every subsequent one after gives me this error.
Thanks!
Once that happens, I get this error message on vim startup -
"gutentags: The tags file is already being updated, please try again later.
Press ENTER or type command to continue"
Original tags file is generated using this command -
"ctags --extra=+f -L cscope.files"
Hint for project root is to look for the existing tags file.
let gutentags_project_root=["tags"]
My project code base is really huge, so cscope.files is the list of files that I'm interested in. Is it possible that gutentags is going through the entire project codebase and trying to generate tags for everything? It would probably take it minutes to do so.
I don't know if this is a bug or a feature request, but I'm noticing that when ctags is run by gutentags it indexes everything in the project, even when I have a .ctags
file with --exclude=[something]
.
This may be outside the scope of the gutentags---I know there's a variable g:gutentags_exclude
that has the desired behavior---but I'd like to get the same output from running ctags -R
in the project root as I get with this plugin...without having exclusions defined globally in $HOME/.ctags
, my .vimrc
, or a vim modeline.
I'll take a look at the code myself and see if there's an easy fix, but I thought I'd put in an issue, too.
Edit: I also see g:gutentags_options_file
, but again I'd rather avoid cluttering my .vimrc
. I guess I can set up an autocommand to reset that variable for each file I open...?
It would be nice to have support for language specific tags executables (For example jsctags). These executables do not always have flags with the same names as ctags. I suggest using something similar to what easytags uses:
let g:easytags_languages = {
\ 'language': {
\ 'cmd': 'jsctags',
\ 'args': [],
\ 'fileoutput_opt': '-f',
\ 'stdout_opt': '-f-',
\ 'recurse_flag': '-R'
\ }
\}
Seems as if gutentags is suprised to see filenames with spaces under OpenSuse 13.2 (I recall from your blog entry that you only tested it under Mac and Windows though):
"~/.config/autokey/data/My Phrases/Dsg.txt" [noeol][mac] 1L, 21C
No location list
Error detected while processing function <SNR>192_setup_gutentags..<SNR>192_update_tags:
line 88:
E172: Only one file name allowed: chdir /home/konfekt/.config/autokey/data/My Phrases
Error detected while processing function <SNR>192_setup_gutentags:
line 45:
E171: Missing :endif
If automatic tag generation is disabled then either :GutentagsUpdate
should not be defined or still work (to update tags manually).
opening my ~/.vim/vimrc in vim, making a quick edit and then closing it gives me the following everytime I open it afterwards:
vimrc on Linux Mint 17 (Basically Ubuntu 14.04) gives the error.
"vimrc" 471L, 13009C
autotags: The tags file is already being updated, please try again later.
Press ENTER or type command to continue
removing the tags.lock file fixes this temporarily
I expect that if I am opening a file with vim, I shouldn't get the error. Since it's possible that the file was modified in between, for example changing a git branch, it should restart silently generating the tags.
I'm honestly not sure, on a different level, if ctags can handle a vimrc file anyway.
I recently installed Gutentags and, while it appears to work wonderfully when I open a file inside one of my projects with a .git folder, it takes EXTREMELY long (~30 seconds) for Vim to open a file in ~/ (such as my .vimrc)
I enabled the tracing and this is what I get when attempting to edit ~/.vimrc:
gutentags: Scanning buffer '/home/rslindee/.vimrc' for gutentags setup...
gutentags: Can't figure out what tag file to use... no gutentags support.
Note that the second line doesn't appear until after approximately 30 seconds of searching. I tried putting a .notags file in my ~/ directory, but it made no difference.
Any suggestions would be greatly appreciated, as I think this plugin shows a great deal of promise.
Edit - Additional info:
-The long delay doesn't seem to occur if I open Vim in the root directory. That said, the delay occurs if I attempt to open Vim inside something like /bin
-This is inside a Cygwin environment
-It seems like the algorithm for finding "project markers" in parent directories is taking way too long when there are no such project markers to be found
I would like to access the standard go library from my own repo.
If I comment gutentags from my .vimrc and run ctags -R /user/local/go/src .
it generate the correct tags file. Is there a way to tell gutentags about my external directory? I read in the docs about .gutctags but I am not sure what should be it's content. I tried this:
ctags
-R
/usr/local/go/src
.
and other variations but nothing worked.
There is no mention of g:gutentags_generate_on_new
in the documentation.
I've noticed that a full update (GutentagsUpdate!
) would use relative filenames, but a partial update for the current file (GutentagsUpdate
) absolute ones.
This causes Vim (Neovim) then to display the tag selection with :tj
, because the path differs.
Can you confirm this?
I am using universal-ctags, and reported the issue there in a pull request, which fixes this when using --tag-relative=yes
: universal-ctags/ctags#868.
Since the code in this area appears to date back to the early days of ctags, I assume that this affects gutentags in general?!
A fix might be to make UPDATED_SOURCE
local to the tags file?!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.