tags.lock and tags.temp files after few saves about vim-gutentags HOT 22 CLOSED

👍 The gutentags: The tags file is already being updated, please try again later message is totally obnoxious. This does not deserve a "Press ENTER". If the plugin is doing its job, I don't need to know about it. I suggest removing that message.

from vim-gutentags.

About the message, that's weird, for me it just displays but does not prompt to press Enter? (it just flashes in the status bar). Got any idea what the difference might be?

About the original post, yes, Gutentags will go through the entire project. It's got no way to know to use your cscope.files filter, or any other filter for that matter. So what might be going on is that Gutentags kicks off ctags, then you quit and restart Vim, and the ctags process is still running, so you get the message? Although if you still get the message after the process has ended, then that might be another bug.

from vim-gutentags.

To tell Gutentags about the filter, with the latest version, you could try creating a .gutctags file at the root of your project, with those options in it (I think ctags wants one per line):

--extra=+f 
-L cscope.files

from vim-gutentags.

Okay, I'll give .gutctags a try. Is the version here on github not the latest one? Install instructions ask to use the version from bitbucket. And it does look like bitbucket version was updated more recently.

from vim-gutentags.

Tried .gitctags but the update script is still not using it.

19646 pts/4 S 0:00 /bin/sh /users/ronakg/my-dot-files/vim/bundle/vim-gutentags/plat/unix/update_tags.sh -e ctags -t /nobackup/ronakg/rp3/tags -p /nobackup/ronakg/rp3

19647 pts/4 R 0:30 ctags -R -f /nobackup/ronakg/rp3/tags.temp /nobackup/ronakg/rp3

from vim-gutentags.

The Github version should be the latest one, yeah. I'm using Mercurial primarily, so the version on Github is just a mirror, but it's up to date (I always push to both Github and Bitbucket at the same time actually).

Was that a typo in your second message or did you name the file wrong? It should be .gutctags. See the code here, where it should be adding it as a -o option to the update_tags.sh script, which would in turn pass it to ctags.... of course there's also the possibility of a bug :)

from vim-gutentags.

The typo was in my comment here, the file I created in workspace is fine.

Looks like I need to create .gutctags file where my cscope.files is present. The script doesn't pick up .gutctags file from my home directory, right? I'm not the expert at vimscript.

from vim-gutentags.

Closed by mistake.

from vim-gutentags.

After creating .gutctags at root of the project, the update script is picking up the options but ctags process never finishes.

7843 ? R 9:33 ctags -R -f /nobackup/ronakg/rp3/tags.temp --options=/nobackup/ronakg/rp3/.gutctags /nobackup/ronakg/rp3

from vim-gutentags.

If you run this command line manually, does it complete in a normal time frame?

from vim-gutentags.

No it doesn't. It is going through the entire project (really really huge) because of -R flag. I think when the options file is present, you should not have -R flag for ctags.

from vim-gutentags.

Removing -R flag from ctags works fine.

from vim-gutentags.

I created a pull request to not use -R flag when options file is present.

from vim-gutentags.

I'll have to test when I come back to a computer, but are you sure it actually parses the subdirectories of your project? I get a feeling that, at best, the -R flag should not be present only if there's a file list provided in the options file... Most people would only use the options file only to provide ignore patterns, so they would need the recourse flag...

from vim-gutentags.

are you sure it actually parses the subdirectories of your project?

Yes, when I ran the command manually it showed errors in some files which it should not be scanning.

I get a feeling that, at best, the -R flag should not be present only if there's a file list provided in the options file...

Think of it this way. If a user is providing an options file, it means the user wants to take control of what options are passed to ctags (including -R) and the script should not assume things on its own and pass options to ctags itself.

Anyway, it's up to you to decide.

from vim-gutentags.

I'm mostly worried about the unknown number of users who currently have a .gutctags file that only lists exclude rules, and who, after this change, will see most of their tags disappear.

I think a better way would be to use Ctags' multiple options file support. Make a default options file that comes with Gutentags, which has --recurse=yes in it, and pass that first. Then pass the .gutctags file, in which you can specify --recurse=no if you want to disable that... it's got some downsides, since I could still break something if I add more stuff to the Gutentags default options file later, but that will probably be very rare. Also, it means you don't have to almost always add --recurse=yes in .gutctags, which I imagine many people would forget adding and then file bugs.

I've got the change written already, and it seems to work as expected. Any concerns?

from vim-gutentags.

This approach sounds good to me.

from vim-gutentags.

Done!

from vim-gutentags.

About the message, that's weird, for me it just displays but does not prompt to press Enter? (it just flashes in the status bar). Got any idea what the difference might be?

"Press ENTER" behavior depends on many things, including the height of the commandline, and whether any previous messages were posted before the next redraw. I see this gutentags: The tags file is already being updated, please try again later message on startup often, when I close and re-start Vim quickly. Then I get the "Press ENTER" thing, which is very unpleasant.

What is the purpose of the message? When would the user want to see it?

from vim-gutentags.

Ah ok, got it. The purpose of the message is if the user wants to manually trigger an operation to re-parse the current file or all the files in the project (:GutentagsUpdate!). If ctags is already running, it tells them nothing will be done right away. I guess the proper fix would be to only show the message after an actual user action (running the command) as opposed to an automatic action.

from vim-gutentags.

So that last bit should be fixed with 02a9f07.

from vim-gutentags.

@ludovicchabant Thanks :)

from vim-gutentags.