Mixed relative and absolute paths

[blueyed]

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

[blueyed]

@gruberjuliannama
?

You seem to have pasted parts of my comment and code from the PR (#71)?
Am I missing something?

[ZyX-I]

At commit cbc163f I still have the same problem. When trying to resolve it I used g:gutentags_cache_dir = $XDG_DATA_HOME . '/gutentags/tags' and as I guessed now all paths are absolute, but this does not fix core issue: duplicate entries:

:tag ostream_in_mpack_init
  # при тип  метка                  файл
  1 F C f    ostream_in_mpack_init  /home/zyx/a.a/Proj/c/neovim/src/nvim/api/private/obj_stream.c
               ObjStreamIn ostream_in_mpack_init(ObjStreamReader read)
  2 F C f    ostream_in_mpack_init  /home/zyx/a.a/Proj/c/neovim/src/nvim/api/private/obj_stream.c
               ObjStreamIn ostream_in_mpack_init(ObjStreamReader read)

[ludovicchabant]

The reason you have duplicate symbols seems to be different, as the 2 paths look the same?

[ZyX-I]

I do not think it is different because the way to reproduce is the same:

1. Remove tags file.
2. Do :GutentagsUpdate!.
3. Do :write. If I am not mistaking, this is the same thing as doing GutentagsUpdate.

Also without g:gutentags_cache_dir I have absolute and relative path like @blueyed had. I guess this means that tags file contains two identical entries, but Vim is not removing duplicates.

[blueyed]

FWIW: my issue was fixed with #71 (not merged, because it depends on Python).

[blueyed]

@ZyX-I
Make sure to look at the tags file for the paths - Vim might adjust them, i.e. although one is relative, you see them both as absolute.

[ZyX-I]

This is something else: file contains exactly one entry, but project root contains tags file as well which I remember myself removing before checking behaviour with g:gutentags_cache_dir. So g:gutentags_cache_dir is indeed fixing things for me (unless I have somehow hit an issue when tags file is generated in different locations).

[ludovicchabant]

So let's try to not get confused by various different bugs. The OP was about mixed relative and absolute paths.

To be clear, this is what I figured out when I was writing Gutentags:

• ctags generates absolute paths if an absolute project path is given, and relative paths if a relative project path (such as .) is given.
• The --tag-relative option only works when you pass a relative project path. If you pass an absolute project path, it ignores it and generates absolute paths in the tags file.
• Both the original ctags and Universal Ctags behave like this.

Gutentags has 2 modes: tags file at the root of the project (1), and tags file in some cache directory somewhere (2).

Unless I'm missing something clever, mode 1 can (and probably should) use relative paths, whereas mode 2 should use absolute paths because the cache directory and project directory are probably totally unrelated. This is why Gutentags passes . and a relative tags filename in mode 1, and absolute paths to both in mode 2 (see this block of code). As a result, Gutentags never uses the --tag-relative option.

I believe I fixed the bug @blueyed originally reported with 09fbdfc (I wasn't properly doing that "relative/absolute" switch depending on mode 1 and 2 for single-file updates). The problem is really that I let Gutentags put the tags files in a cache directory, so I don't personally test much "mode 1" (I have to look into automated Vim testing to make sure I don't break things).

[MaikoID]

Hey guys, I want to congratulate you all for all work done so far but I can't get satisfied with it, there are so many bugs. Is there any stable release with a minimum functionality any where?

Currently I'm having the same issue, if I enable the cache with:

let g:gutentags_cache_dir = $XDG_DATA_HOME . '.tags'

The duplicate continues to occur but without the mix, all tags remains duplicated with full path.

[ludovicchabant]

I haven't set up branches or labels, no, but you're right, I should probably do that at some point (whenever we can actually identify a "stable" release, really).

Since you're using $XDG_DATA_HOME I assume you're on some Unix-flavored OS? (I'm asking because I noticed that on Windows, it's easy to get mixed slashes/backslashes, which can confuse Gutentags and you end up with duplicates with different slash orientations).

[MaikoID]

Hi @ludovicchabant thanks for you answer.

I think that I resolved the problem removing the option cscopetag from my nvimrc and keeping the cache option;

[cbrwizard]

I had this issue when I had tags generated by a command

ctags -R --languages=c# --exclude=.git --exclude=log .

And after that I opened a folder I generated ctags for with Vim with this plugin installed and I saw the duplicated tags with absolute and relative paths. Then I quit vim, removed the tags file and ran a :GutentagsUpdate command. This helped, now Ctrl+] goes to a correct definition without showing the duplicates.

I am new to Vim (learned about ctags just 2h ago) so it's not a surprise that I did something wrong here. Hopefully my solution will help the other newbies [: