ludovicchabant / vim-gutentags Goto Github PK

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

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.

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.

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.

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 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'
\   }
\}

If automatic tag generation is disabled then either :GutentagsUpdate should not be defined or still work (to update tags manually).

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 ) .

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?

If .vimrc contains let g:gutentags_enabled = 0 then saving a file in a git repo still makes ctags recreate the tags file.

Fixed in blueyed@9ef876f (based on / included in #72).

btw: here is a integration branch with all my recent PRs: master...blueyed:integration

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.

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.

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

It would be nice if you can support GNU Global or Cscope as I find ctags inadequate for large code bases.

Good work.

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?).

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.

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

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

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 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.

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...?

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.

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...

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?

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.

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 .ctagsfile:

--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

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?

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?

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

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.

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?!

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

There is no mention of g:gutentags_generate_on_new in the documentation.

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.

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

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?

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!

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)

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,

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

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?

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]

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.

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"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "/.vim/gvimrc"
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