Windows tags files use a double-backslash directory separator, which shows up in Vim

[rnk]

When I run universal ctags on Windows, the tags files contain paths with two backslashes. This is annoying because it's visible in Vim when I jump to the tag definition. Consider this line from my tags file for LLVM:

ilist_node_with_parent	llvm-project\\llvm\\include\\llvm\\ADT\\ilist_node.h	/^class ilist_node_with_parent : public ilist_node<NodeTy, Options...> {$/;"	c	namespace:llvm

In Vim, the displayed file path is llvm-project\\llvm\\include\\llvm\\ADT\\ilist_node.h, instead of llvm-project\llvm\include\llvm\ADT\ilist_node.h.

It would be nice if there was an option to force the use of forward slashes on Windows, which appear to do the right thing in Vim.

[masatake]

Could you try --output-format=e-ctags option?
I don't have an access to WIndows PC.

[rnk]

Yes, that fixes my issues. I get tags lines like this:

ilist_node_with_parent	llvm-project\llvm\include\llvm\ADT\ilist_node.h	/^class ilist_node_with_parent : public ilist_node<NodeTy, Options...> {$/;"	c	namespace:llvm

I had to delete a line from the VS project file to get it to build. I'll send the patch along.

[ludovicchabant]

Would it be possible to make Universal Ctags output proper single backslashes on Windows by default? What's the backstory here for those double backslashes?

Every time I setup a new Windows machine I forget about this, wonder why my tag files are messed up and why Vim is unhappy, and then remember to change the output format locally.

[masatake]

Please, put --output-format=e-ctags to $HOMEDRIVE$HOMEPATH/ctags.d/*.ctags.
Suprisingly I cannot find any document for this topic.
This should be written in ctags-incompatibilities.7.

[masatake]

It is related to format-3 branch. The branch is corrupted because I mistakenly the branch to master.
I must inspect the status of format-3 branch.

[ludovicchabant]

Yep, adding the option to my global ctags config file is what I end up doing, but I don't think that should be needed, should it? I don't know why it does those double-backslashes, but if there's something I can do to help (like testing or whatever), feel free to ping me.

[masatake]

I will explain why. I have to write this to our man page. Maybe the format-3 branch includes some documentation about this topic.

One of this motto in Universal-ctags development is that ctags should pass raw-data to client tools; ctags should not hide raw information found in the input files.
Here, the client tools include vim, readtags, etc. Dropping information can be done later in the client tool side.

tags format uses tab characters as a separator between fields.

[jet@living]~/var/ctags% cat /tmp/input.c
int x;

[jet@living]~/var/ctags% u-ctags -o - /tmp/foo.c
x	/tmp/input.c	/^int x;$/;"	v	typeref:typename:int

Here a tab char is used between x, /tmp/input.c, /^int x;$/;", v, and typeref:typename:int.

Here we call the field holding x in the example out "name" field.
We call the field holding /tmp/foo.c in the example out "input" field.

If a name field filled by a parser (Foo) includes tab characters like n a m e, ctags can emit broken tags file:

n	a	m	e	/tmp/input.foo	/^</title>n	a	m	e</title>$/;"	t

A client cannot distinguish the tab characters in the name field and the tab characters placed as a separator.

So we introduce the escape sequence. When printing a field including a tab char, ctags replaces it with \t.
This escape sequence introduces a new issue; how we should do if a filed includes a \ char?
The our solution is that ctags replaces it with \\.

[masatake]

It is possible to make a file including a tab char in its name at leat on Linux.

[k-takata]

Just an idea. How about using / for directory separator even on Windows?
At least, Vim can handle a tags file with /. (Another work might be needed to support a name with \t.)
As a side effect, a tags file created on Windows might be able to share with Linux. (Line endings should be LF instead of CRLF, then?)

[masatake]

@ludovicchabant, how do you think about @k-takata's idea?

[k-takata]

#2199 was merged, so no need to use --output-format=e-ctags now.