Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the XDG Base Directory Specification #142

Closed
severen opened this issue Oct 15, 2015 · 32 comments

Comments

@severen
Copy link

commented Oct 15, 2015

Configuration files should be stored under $XDG_CONFIG_HOME (which defaults to ~/.config)

For example:
~/.tmux.conf => $XDG_CONFIG_HOME/tmux/tmux.conf or $XDG_CONFIG_HOME/tmux/config.conf

This blog post lists the advantages of using the XDG Base Directory Specification as follows:

  • $HOME is a lot less cluttered.
  • Backups are a lot more safer and easier. (you know that backuping your $XDG_DATA_HOME along with your files is enough)
  • A lot easier to reset a default configuration if you want/need it (and without any risk of loosing information).
  • Avoid some strange bugs that happen because you had a old version of some configuration file.
  • It is a lot more flexible and portable because no paths are hard-coded. You can use the XDG library that does the job for you or, if you don’t want the dependency, implementing the XDG specification is only a few lines of code.
@ThomasAdam

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2015

Discussed before on the mailing list. The outcome: thanks, but no thanks. If you want this, symlink it.

@ThomasAdam ThomasAdam closed this Oct 15, 2015

@sector-f

This comment has been minimized.

Copy link

commented Jan 11, 2016

May I ask why/how that decision was made? Searching for "xdg" on the mailing list (this is the mailing list, correct?) didn't return any results

@ThomasAdam

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2016

http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/3376

Still not going to happen.
On 11 Jan 2016 03:44, "Adam" notifications@github.com wrote:

May I ask why/how that decision was made? Searching for "xdg" on the
mailing list (this https://groups.google.com/forum/#!forum/tmux-users
is the mailing list, correct?) didn't return any results


Reply to this email directly or view it on GitHub
#142 (comment).

@drbrain drbrain referenced this issue May 5, 2016

Closed

Rubygems does not comply with XDG basedir spec #1599

1 of 5 tasks complete
@caesar

This comment has been minimized.

Copy link

commented May 29, 2016

@ThomasAdam What is the rationale for the decision not to support this, since no rationale has been given either here or in the mailing list?

Your proposed symlinking solution doesn't solve the problem at all – I still have .tmux.conf in my home directory; the only difference is that it is now a symlink to somewhere else instead of an actual file.

@ThomasAdam

This comment has been minimized.

Copy link
Contributor

commented May 29, 2016

In order to support it, we'd have to make the configuration file loading platform-specific, which would be a pain to support.

@caesar

This comment has been minimized.

Copy link

commented May 29, 2016

No you don't; you just have to check for the existence of $XDG_CONFIG_HOME/tmux/tmux.conf and use it if it exists. Should be no more than a few lines of code. (I know a patch sent before and rejected was seven; I haven't looked at it myself.)

@krader1961

This comment has been minimized.

Copy link

commented May 29, 2016

you just have to check for the existence of $XDG_CONFIG_HOME and use it if it exists

That is incorrect. The XDG base directory standard requires that you use the default $HOME/.config if that env var isn't set. So in reality tmux would have to check for $HOME/.tmux.conf. If that doesn't exist check for $XDG_CONFIG_HOME/tmux/tmux.conf if $XDG_CONFIG_HOME is set else $HOME/tmux/tmux.conf. Personally I'd like to see that implemented. But it is a trifle annoying to see people argue "it's easy, just a few lines of code" when asking someone else, who isn't getting paid to maintain the code, to implement a feature.

@caesar

This comment has been minimized.

Copy link

commented May 29, 2016

@krader1961, Sorry, I wasn't clear, and you are absolutely right. I didn't mean checking for the variable; I meant checking for the existence of the file in question. (Which would be either $XDG_CONFIG_HOME/tmux/tmux.conf or, if the variable $XDG_CONFIG_HOME isn't set, $HOME/.config/tmux/tmux.conf.)

The argument about asking someone else to implement the feature is fallacious. A patch has already been offered and rejected (not because it was badly coded but because the core devs don't want the feature implemented), and I for one would also be happy to provide a patch if this feature would be accepted.

Actually I would say that type of argument is self-perpetuating. By assuming the core devs are the only ones capable of contributing to a project and brushing off outsiders with ideas/patches, you ensure that the core devs do have to do everything by themselves. The result is that the project stagnates. The end result with Vim was a fork.

@sector-f

This comment has been minimized.

Copy link

commented May 29, 2016

Actually it'd be: check if $XDG_CONFIG_HOME is set then look at either$XDG_CONFIG_HOME/tmux.conf or $HOME/.config/tmux.conf. Then look at $HOME/.tmux.conf for backwards-compatibility, I guess

@caesar

This comment has been minimized.

Copy link

commented May 29, 2016

@sector-f, exactly. My point is, nothing platform-specific (or overly onerous).

@sector-f

This comment has been minimized.

Copy link

commented May 29, 2016

Right. Tmux is already looking for a file at startup. This would just be a few more lines.

@krader1961

This comment has been minimized.

Copy link

commented May 30, 2016

This would just be a few more lines.

Plus unit tests. Plus documentation. Plus deciding what to do if both config files (old location and XDG) exist. What happens when someone forgets to remove $HOME/.tmux.conf when they create an incompatible XDG config file and they report unexpected behavior? Too, it's debatable whether the XDG location should be checked first or the legacy location. Seemingly trivial changes are seldom trivial.

The previous discussion and proffered patch was 3.5 years ago. That change didn't update the documentation (although that wasn't a factor in it being rejected). The XDG base directory specification at the time was not in widespread use. That is no longer true.

As I earlier stated, I too would like to see support for it added to tmux and every other program that puts a config file in my home directory. Like you I'm a bit perplexed why @nicm is against this. It doesn't require new CLI flags or config file changes (other than accommodating a new location for it). But blithely saying idiotic things like "this would just be a few more lines" of code isn't the way to get someone who created a project to agree to implement a feature. Even if they're not being asked to write the patch.

@sector-f

This comment has been minimized.

Copy link

commented May 30, 2016

Alright, so some decisions have to be made. No shit. That's true about everything. But regardless of the outcome of those decisions, it's still just a few additional lines of code. The changes to the documentation would be minor.

By the way, if you want to convince someone your position is correct, perhaps you should avoid calling what they say "idiotic."

@caesar

This comment has been minimized.

Copy link

commented May 30, 2016

@krader1961 I agree with much of what you say, despite the hostile tone. Clearly there are a few considerations beyond the actual coding, and there is a requirement for a few decisions to be made.

To answer your question, my preference would be for the XDG location to have priority, and the $HOME one to be ignored if both exist. However an alternative would be to load one and then the other, like Git does, which would probably reduce the support burden if you think that will be an issue (I doubt that it will, with proper documentation). Naturally the project maintainers would have the final say on which strategy was followed, were this to be implemented.

I feel like the goalposts are moving here though. I respond to @ThomasAdam and explain why it's not platform specific as he had stated, and you come back with "oh but it would need documentation" etc. Yes, it would, but that wasn't @ThomasAdam's objection.

Anyway there's not much point in arguing about it if the project maintainers have already made up their mind. Let's all get on with more productive things and resign ourselves to the fact that 'free' so often means a very different thing to 'open'.

@nicm

This comment has been minimized.

Copy link
Contributor

commented May 30, 2016

@grawity

This comment has been minimized.

Copy link

commented May 30, 2016

Makes sense. Though, the primary difference from those previous ~/.tmux* suggestions is specifically to reduce the clutter in one's homedir – lots of dotfiles in ~/ add up as well – thus symlinks or "source" would somewhat defeat the point.

(Edit: Not to mention that one would end up with a lot of aliases and envvars that way.)

(True, it won't ever go away, but small steps. Overall, I've seen various other CLI programs – such as git, htop, lftp, mpd, neovim – switch over to the $XDG locations, usually while keeping the old path as a fallback, so it's definitely not "X11-specific" anymore, and by now not particularly Linux-specific either.)

@severen

This comment has been minimized.

Copy link
Author

commented May 30, 2016

Also, defining aliases and such for things like tmux -f $XDG_CONFIG_HOME/tmux.conf also shifts the clutter from one's home directory, to their shell config files. Granted it isn't as in your face as it would be under $HOME.

Also, using a dot to hide files actually stemmed from a mistake: https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp. Doesn't really have a lot of relevance now, but it's an interesting tidbit nevertheless.

@nicm

This comment has been minimized.

Copy link
Contributor

commented May 30, 2016

@sector-f

This comment has been minimized.

Copy link

commented May 30, 2016

Personally, I think having a directory specifically for configuration files is nice.

We could make programs look for global config files in /. But we don't, because that would cause clutter and having specific directories for specific purposes is useful. In this case, we have /etc/.

I believe having a similar standard for users' config files is at least equally useful, if not moreso—I personally look at the contents of my home folder much more than I look at the rest of my system.

@caesar

This comment has been minimized.

Copy link

commented May 30, 2016

@nicm, thanks for your very rational and reasonable response. It's so much easier to respect a decision when the rationale is put forward than when it is just a "not going to happen" (with an implied "and go away please").

Though I disagree with your rationale (XDG is becoming increasingly common and is not Linux-specific - I am on OS X, a BSD derivative, and most of my commandline software follows XDG), I can respect it and live with it.

One proposal, which might perhaps satisfy your concerns about not following patterns considered platform-specific (or ecosystem-specific): what about just having a tmux-specific environment variable, such as $TMUX_CONFIG? This could be set by those who care, on any platform, and ignored by everyone else. It would be a much cleaner solution than defining aliases to tmux.

@maletor

This comment has been minimized.

Copy link

commented Sep 22, 2016

Discussed before on the mailing list. The outcome: thanks, but no thanks. If you want this, symlink it.

So the mailing list conversation seems to be deleted or moved.

Regardless, I think your attitude is a little short sighted. The actual specification makes a ton of sense and it's been implemented by projects like git and mpv since it was created in 2003.

@ThomasAdam

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2016

@maletor - read the other comments on this issue as well. They won't change what you're asking for though. Have a nice weekend.

sds added a commit to sds/dot that referenced this issue Oct 1, 2016

Load tmux configuration from XDG-compatible directory
In an effort to move this configuration into a self-contained `.config`
directory, update special `tmux` function to load different
configuration in the default case.

This is necessary since the tmux developers have decided to not support
XDG: tmux/tmux#142
@HaleTom

This comment has been minimized.

Copy link

commented Oct 8, 2016

tmuxinator is also considering supporting the XDG Base Dirs Spec: tmuxinator/tmuxinator#360

To me, @caesar's idea of an environment variable seems easiest as it removes the need to work out what to do in the case of two configuration files, however 5 years from now, we may be asking why we chose the easiest path...

@ThomasAdam

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2016

@HaleTom -- this is a really moot point, and you're peddling this for no valid reason.

@jcrben

This comment has been minimized.

Copy link

commented Nov 10, 2016

Those who want this could check out byobu which supports XDG http://byobu.co/documentation.html

@alcohol

This comment has been minimized.

Copy link

commented Nov 21, 2016

Aww, sadness. Seeing an awful lot of resistance towards adding a feature that would merely enable functionality a subset of users desires, while not hampering existing users at all. So much for open source :-(

@HaleTom

This comment has been minimized.

Copy link

commented Nov 21, 2016

Agree. I could understand "not a priority, but make a pull request".

FYI, I just finished the PR for tmuxinator

@ValentinKlinghammer

This comment has been minimized.

Copy link

commented Sep 15, 2017

Another reason for $XDG_CONFIG_HOME is that a lot of people are versioning their config files in a repo nowadays. It's much easier and cleaner for those users if there is a single, configurable directory for those files, instead of just simply dropping them in the root of the home directory.

Not sure why the platform would even matter, I use that approach on macOS as well as Linux, pretty much everywhere where you can use an environment variable.

I currently use tmux like this alias tmux='tmux -f $XDG_CONFIG_HOME/.tmux/tmux.conf' but would prefer it if tmux would support that spec.

@HaleTom

This comment has been minimized.

Copy link

commented Sep 16, 2017

@ValentinKlinghammer thanks for pointing out -f.

Some changes:

  1. Use quotes around the variable, just in case of spaces or strange characters
  2. Most directories in $XDG_CONFIG_HOME don't start with a . -- remove it
alias tmux='TERM=xterm-256color tmux -f "$XDG_CONFIG_HOME"/tmux/tmux.conf'
@qrevel

This comment has been minimized.

Copy link

commented Sep 19, 2017

@ValentinKlinghammer an alias with a -f seems to be a great workaround.
I can't make it work with tmuxinator v0.9.0. It keeps ignoring the XDG compliant tmux.conf.

@HaleTom

This comment has been minimized.

Copy link

commented Sep 19, 2017

@ValentinKlinghammer, in your ~/.config/tmuxinator/default.yml include:

tmux_options: -f "$XDG_CONFIG_HOME"/tmux/tmux.conf
@qrevel

This comment has been minimized.

Copy link

commented Sep 19, 2017

@HaleTom thanks it worked with tmuxinator v0.10.0

arumoy-shome added a commit to arumoy-shome/dotfiles that referenced this issue Oct 20, 2018

tmux: make tmux xdg complient
load tmux config from xdg_config_home/tmux, taken from:
tmux/tmux#142 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.