Tags file not sorted error

[reidrac]

This is with ctags. Sometimes (not for all the tags, that is) tying to autocomplete with CTRL + N I get this error:

Scanning tags.                                                                                                                                                                                                        
E432: Tags file not sorted: /home/user/.cache/tags_dir/homeusersrc/prj_tags                                                                                                                
Press ENTER or type command to continue                                                               

I press enter and it seems to work as expected.

Not sure if this is an issue, but I never experienced this before when using ctags.

[reidrac]

The tags file claims to be sorted:

!_TAG_FILE_FORMAT   2   /extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED   1   /0=unsorted, 1=sorted, 2=foldcase/
...

Btw, this is vim 8.1.

[jsfaint]

I believe It's issue in ctags.

When generate all ctags, this command will be called

ctags --extras=+r -f <tag path> -R <src path>

On update tags (file save), this command will be called

ctags --extras=+r -f <tag path> -a <src file>

The tag will be sorted after generating, but in append mode, the new tag will insert in the end of the tag file. I think it's why you get this issue.

But it's weird that I DO see the unsorted tag, but I CANNOT see the error message.

Which version of ctags do you use? I use universal-ctags r6630

Can you try to add this line in your vimrc? And regenerate the ctags then check if the issue happens again.

let g:gen_tags#ctags_opts = '-u'

[reidrac]

It is Exuberant Ctags 5.9~svn20110310 with "+wildcards" and "+regex".

Looks like let g:gen_tags#ctags_opts = '-u' gets rid of the problem. What are the consequences of not having the tags file sorted?

[jsfaint]

not sure, maybe some little performance issue I guess😂

Thanks for the clarification!

[reidrac]

I'm giving gtags a go, but it doesn't support Scala and it is a bit fiddly to setup to be honest.

If gtags work, I'll use that, otherwise I'll see how that -u performs (my codebase is not huge anyway).

Thanks for your help! Feel free to close this ticket if is not an bug.

[jsfaint]

gtags can use ctags or pygments for extension to support extra languages. But it requires some config.

[reidrac]

I managed to make it work with pygments (no luck with ctags, it ignores my ~/.ctags rules for Scala).

Pygments is a bit slow, but it does the job. I'll use it like this for a while and see how it goes.

Thanks again for your help!

[jsfaint]

It's my pleasure😄

[reidrac]

In case someone comes to this bug report, this is what I did in Ubuntu 18.04:

1. Copy the example gtags conf file: zcat /usr/share/doc/global/examples/gtags.conf.gz > ~/.globalrc
2. Edit it and replace pygments-parser.la with pygments-parser.so (it is just the extension)
3. Set environment variables: export GTAGSLABEL=pygments and export GTAGSCONF=~/.globalrc (add those two to your ~/.bashrc)

You'll need python-pygments installed (I believe it requires the Python 2 version).

My vim conf didn't require any change.

[reidrac]

Also for the record: the -u flag in ctags doesn't help at all, vim will complain the tags aren't sorted.

[jsfaint]

@reidrac I don't use completion directly, but with some completion framework, it works well. That's werid And can you try universal-ctags instead of the Exuberant tags?

[reidrac]

I gave up with ctags directly and instead I'm using gtags (with plugins for ctags or pygments, as needed). It doesn't seem to be affected by this issue, but I wanted to clarify that the -u workaround with ctags doesn't work (the resulting file is indeed unsorted, but vim requires it to be sorted I guess).

It makes sense it doesn't because it appends sorted tags but is not sorting the tags file so at the end you may have entries that aren't sorted. Why this never happened with vim-easytags? I don't know, may be it did a smarter "merge" of the the updated tags and the existing tags file.

gtags seems to not have this problem because the tags DB management is better.

[jsfaint]

got it, thanks for the information🙂

[jsfaint]

The season that it doesn't happen with easytags, it is very simple.. easytags do not use append mode, it always generate all the tags again and again. That's why easytags will froze the editor.

[reidrac]

Easytags supports asynchronous execution (it is experimental, but it works fine for me).

Easytags ticks lots of boxes for me (tag highlighting is very useful, even if it is a bit expensive), but gen_tags has better tags management (~/.cache when using it on a git repo is a killer feature IMHO). And well, now that I'm using gtags, it includes few tricks I'm getting used to very quickly.

[jsfaint]

I implemented async support in the original code even before neovim appear. And in that time, append mode was also disabled. Then I got a feature request for append mode, and later it became buggy🤣 I keep fighting with ctags append mode and try to prune the old tag for append mode. I'm a little regret to support it. 🤣

[reidrac]

I see why ctags is needed, I would suggest you:

• Improve gtags support and documentation on using it with the ctags plugin
• Drop ctags support

I've found gtags docs a bit lacking and it is a bit "complicated" to configure (it doesn't help that Debian example conf file had a couple of issues loading the plugins), but once it is working, gtags is better interface to ctags than ctags itself.

I'm not sure if there are any downsides to this approach. Probably related to tools that may use ctags files directly and don't support gtags.

In any case, thank you again for gen_tags!

[jsfaint]

Thanks for the advice! I will complete the document when I get some spare time.😄

[jsfaint]

I Changed the behavior of g:gen_tags#ctags_prune, if this option is set to 1, prune and append mode will be used, otherwise it will always re-generate the tags file. And I also added help doc about how to set global parser(ctags/pygments)

The code is in refactor/ctags branch, not merged yet