Use relative path also with absolute filename

[blueyed]

I have noticed that with gutentags [1] absolute paths would be used when
only the current file gets updated via --append /absolute/path/to/file.

I cannot see why an absolute path should be used in that case, but have
not checked if that behavior differs from the original ctags, but it
appears to date back to 2001 [2].

This uses an absolute path only with --tag-relative=no.

1: https://github.com/ludovicchabant/vim-gutentags
2:

ctags/read.c

Line 78 in 568742a

if (! Option.tagRelative || isAbsolutePath (vStringValue (fileName)))

[coveralls]

Coverage remained the same at 82.43% when pulling fe003ab on blueyed:use-relative-always into 5b8a9ed on universal-ctags:master.

[blueyed]

The command being run is ctags -f "tags.temp" --options=/home/user/.dotfiles/vim/neobundles/gutentags/res/ctags.options --exclude=*.o … --exclude=*/__pycache__/* --append "/path/to/file".

There seems to be a more in-depth issue here, because it's confusing that relative paths are being used from the beginning?!
This might come from

ctags/main/read.c

Lines 169 to 176 in 791e1bb

	if (isAbsolutePath (vStringValue (fileName)) || File.path == NULL)
	pathName = vStringNewCopy (fileName);
	else
	{
	char *tmp = combinePathAndFile (
	vStringValue (File.path), vStringValue (fileName));
	pathName = vStringNewOwn (tmp);
	}

[coveralls]

Coverage remained the same at 82.43% when pulling 791e1bb on blueyed:use-relative-always into 5b8a9ed on universal-ctags:master.

[masatake]

I introduced the code.

[blueyed]

@masatake
Do you mean that the original ctags is not affected?

[masatake]

I didn't inspect yet however, the line you spotted (

ctags/main/read.c

Lines 169 to 176 in 791e1bb

	if (isAbsolutePath (vStringValue (fileName)) || File.path == NULL)
	pathName = vStringNewCopy (fileName);
	else
	{
	char *tmp = combinePathAndFile (
	vStringValue (File.path), vStringValue (fileName));
	pathName = vStringNewOwn (tmp);
	}

) was modified
by me when I worked on improving input stream interface.

[blueyed]

@masatake
I think I got confused because of the fact that files are relative to the current dir by default (which is good), but just not when an absolute path is passed in - which seems to be old code.

[kopischke]

@blueyed absolute paths are an important feature when your tag files are not stored in the project root (for instance, if you use commit hooks an store the tags file in .git like Tim Pope does).

[blueyed]

@kopischke
I see.
However also in this case, you could/should cd to the tags file dir before?! (and the git hook will put you in the repo root already, which should result in relative paths already)

Apart from that, this PR/patch only affects ctags /path/to/file - while ctags -R would use relative paths already.
Maybe the real fix for my issue (with gutentags) is https://github.com/ludovicchabant/vim-gutentags/pull/71/files after all, where passed filenames are made relative instead?!

[kopischke]

@blueyed .git is not the repo root, it’s its plumbing; moving there before generating tags sounds like a complicated way to do what absolute paths achieve more simply.

[blueyed]

@kopischke
But the hooks are run from the repo root (not from .git and not from .git/hooks) for me?!
(checked sneaking in a pwd).

My setup: blueyed/dotfiles@c42e206

[kopischke]

@blueyed exactly that is the issue with relative tag file paths in these setups: they are generated relative to the repo root, but Vim takes them as relative to the tag file location.

[blueyed]

@kopischke
Ah.. I put my tags files in the worktree, not .git.

Anyway, I do not think this PR changes that behavior:

• tpope uses --tag-relative, which makes them relative to the tags dir
• git ls-files outputs relative file names

[masatake]

       --tag-relative[=yes|no]
            Indicates that the file paths recorded in the tag file should be relative to
            the directory containing the tag file, rather than relative to  the  current
            directory,  unless the files supplied on the command line are specified with
            absolute paths. This option must appear before  the  first  file  name.  The
            default is yes when running in etags mode (see the -e option), no otherwise.

Look at " unless the files supplied on the command line are specified with
absolute paths."

I cannot see why an absolute path should be used in that case,

Because an absolute path is given.

[blueyed]

@masatake
Yeah, this issue is about changing this behavior then after all.

But I can see that this could break things for people.
IMHO with an explicit --tag-relative=yes it should be relative always.

As for now, and with the legacy ctags, it needs to be fixed in the scripts (like in ludovicchabant/vim-gutentags#71).

[masatake]

Though I did in some areas, breaking compatibility should be avoided.
If breaking, we should write about it in our document explicitly.
#778 is an example.

How about introducing --tag-relative=force ?
If force is given, the absolute path rule is skipped. force doesn't exit in exuberant-ctags, so there is no compatibility issue here.

@kopischke, do you have any comment about this approach?

[kopischke]

@masatake adding a --tag-relative flag sounds like the best way to get the behaviour @blueyed is expecting without breaking backward compatibility, and force (or maybe always?) is a good name for that flag.

[masatake]

@blueyed, re-assign this to me if you are not in hurry.

[blueyed]

@kopischke
Good idea. I like always for that.

[kopischke]

@blueyed always would also open the possibility of adding never (which would enforce absolute paths no matter what).

[masatake]

See #893.