Use XDG dirs spec for data/config

[majutsushi]

It would be great if the configuration and other data used by fishman-ctags used the XDG base dir spec instead of putting everything into the home directory. This would keep it in line with other more modern software and would prevent polluting the home directory.

[masatake]

Thank you for input. I will rearrange ~/.ctags.d to conform the specification.
I have to do this before preparing a rpm package.

[fishman]

to be honest with you i'm not a big fan of xdg. what is the advantage of having that dependency and breaking every tool that is using .ctagsrc?

[vhda]

We can always do a small check for the presence of that file, it wouldn't
slow down the runtime that much.

[masatake]

fishman-ctags has enough ability to deal multiple directories. Its design is inspired from systemd.
As far as I know systemd uses the most advanced technique in this area(and another areas, too).

Two problems are.

1. where I should map ~/.ctags.d/drives where user own executables are stored to,
2. I have worked on directory related topics in fishman/ctags more than 6 months. I want to work on another topic:-P

Anyway, this is important. We have to fix the directory structure before fishman-ctags becomes too popular.

Please, look at hacking guide. Currently fishman/ctags deals with 3 types of directory:

1. optlib,
2. corpora, and
3. drivers (executable)

In addtion I plans

1. flavor, and
2. transformers (executable)

Question is should we permit an user to override executables bundled as part of fishman/ctags?

/usr/libexec/ctags/drivers/conffetag, an executable, is installed as part of fishman-ctags.
Do you think a user wants overriding this by putting one own script (or program) at ~/.ctags.d/drivers/coffeetag?

Till yesterday, I believed user may want. However, no directory for executables are defined in XDG spec.
If we don't provide the default way to override executables, it becomes much easier to follow XDG spec.
I'm talking about "default way". fishman/ctags has --libexec-dir option. So a user can add an extra directory for searching executables.

Though I want to fix the directory structure before preparing a rpm package, we need more feedbacks from users about the current directory structure I designed and implemented...we may have to delay the decision.

[majutsushi]

For executables and things like that it might make the most sense to follow this: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
I also wouldn't see much of an issue with putting these things into the data directory, though (probably a subdirectory in that case).

[fishman]

i don't think we should deliberately follow systemd design just because. there are certain things that are nice in it, but not all of it is.

[masatake]

@majutsushi thank you for input.
I've found a quite good person who gives us real feedback about /usr/share/ctags/optlib usage.
Please, wait.

[cweagans]

Sorry for the noise. Just switching the "Release blocker" tag for the "Initial release" milestone so that everything is tracked in one place.

[masatake]

xcmd is gone. Therefore this issue is much simplified.
Both Exuberant-ctags and Universal-ctags accesses ~/.ctags may be a trouble because Universal-ctags introduces many options and incompatible changes in command line handling.

One of the candidate is ~/.u-ctags.d/ directory or XDG base dir spec mentioned here.

I must solve this issue before updating the man pages.

[masatake]

I would like to remove /etc/ctags( and ctagd.d). It is also shared with the both implementations.
I wonder what I should do about windows.

[masatake]

Temporary I decide not introducing XDG dir.

[blueyed]

It would have been nice to go with the XDG spec when moving config to ~/.ctags.d anyway.
I would still think that using $XDG_CONFIG_HOME (defaulting to ~/.config) as a prefix makes sense, i.e. ~/.config/ctags.d then by default?!

[justinmk]

Very much agreed with @blueyed . After reading the long discussion at #1519 I'm completely confused about why a new directory was chosen, it doesn't follow XDG conventions, and the same path can't be used for Windows...?

BTW creating a dot-prefixed directory in Windows is not difficult. Anyone using ctags knows how to use the shell to do so; why would they use Explorer...?

[cweagans]

If ~/.config/ctags.d is what we'd need to do in order to follow XDG, I guess that's okay, but my preference would be to drop the .d (i.e. just ~/.config/ctags)

[fishman]

@cweagans same here. If XDG is a given there's no point in keeping the .d

[dsifford]

@masatake @cweagans Should this issue be reopened? Has support ever been added for this/is this still being considered?

[masatake]

@dsifford, you can reopen it, of coruse. However, I will not work on the item till releasing.
You can make a pull request to implement what you want. As far as you update the documents in the pull request, I will review.

I don't want to take my time for impriving ctags more for this item.

[cweagans]

Reopening in case someone wants to tackle it.

[masatake]

I merged @itchyny's patch. See #2386. However, I wrapped the changes with #ifndef WIN32/#endif.

[BachoSeven]

@masatake did #2386 solve this?

[masatake]

It seems that the answer is yes.

[yamato@dev64]~% strace -e openat ctags
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxml2.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libjansson.so.4", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libyaml-0.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libseccomp.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/home/yamato/.config/ctags", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
...

[hholst80]

Both Exuberant-ctags and Universal-ctags accesses ~/.ctags may be a trouble because Universal-ctags introduces many options and incompatible changes in command line handling.

This is fine. XDG is mostly a cargo cult and often misunderstood by developers in how it should be implemented. If you have just a simple config I'd say look at both $XDG_CONFIG_HOME, then it's default ~/.config and finally under $HOME/.ctags.

.ctags.d looks horrific it is the worst combination of XDG and the "legacy" method.

[masatake]

As we merged #3972, the issue is solved.