Flexible TMux Configuration Load

[weilbith]

The current implementation is hard-coded about where to get the TMux configuration file for read in the listed plugins.
But TMux could be started with a different configuration file. Following the XDG Directory Specification for TMux as also suggested in the ArchWiki, the default location does not fit anymore. In that case the plugin manager is unusable.
To provide a more configurable solution, I've added a new function to search for the TMux configuration in prioritized order.

• First I've defined the optional environment variable TMUX_PLUGIN_MANAGER_CONFIG_LOCATION, which has the highest priority and can be set by the user to anything, regardless if it exists or not.
• On second place the XDG_CONFIG_HOME directory is searched for an TMux entry.
• At least the default one at $HOME/.tmux.conf is taken.

The implementation is super simple, but allows user like me to be more flexible.

[bruno-]

I glanced at the PR and it looks good. I have 2 questions:

• Do we really need TMUX_PLUGIN_MANAGER_CONFIG_LOCATION? I'd rather wait someone requests that feature, than implementing it just because "it might make sense".
• Can you please update indentation? This plugin uses tabs.

Thanks!

[weilbith]

Tabs/Spaces
Sry for that. Have reconstruct them on the recent commit. Maybe it would be wise to set this Vim configuration as comment? 🤔

Variable
I thought it would be nice to make it as easy for the user as possible. First I just implemented the XDG compatibility. Then I recognized, that some applications still use dotted files within XDG_CONFIG_HOM like Zsh for example. So I thought users can stuck again by that (with dot or not). After all I thought it would be the easiest solution for all cases to provide this configurable option.
But I've you don't like it, I can simply remove it.

[bruno-]

@weilbith yea, let's remove the TMUX_PLUGIN_MANAGER_CONFIG_LOCATION variable for now. Let's wait for users to request that feature before implementing it. And returning this functionality (if needed) should be easy.

[weilbith]

Okay, done.

Open questions:

1. Where should I extend the documentation? For example the alternative installation place instructions are not in the default README.
2. Am I allowed to add a Vim configuration comment at the bottom to force the using of tabs? Cause I guess I will not be the only one doing this without purpose.

[bruno-]

@weilbith thanks!

Where should I extend the documentation?

I just added a short note via 42bb2bf. If you have a better idea feel free to open another PR. If the docs are more than a paragraph I'd prefer if it's placed in docs/ dir so it doesn't clutter the README.

Am I allowed to add a Vim configuration comment

I'm a heavy vim user, but I prefer not doing this in any of my public projects. I feel this discriminates all other editors, by indicating preference to vim. Contributors usually figure out the spacing. Having set list in vim could be useful for this.
Also, I kinda regret using tabs for all the plugins. I had "a reason" why I went with it, but now I think the convenience of two-space indentation would be better.

[gnumoksha]

Hi. This improvement came at the right moment for me, but I'm struggling to make this work. Is expected that ~/.tmux/plugins continue being created?

[weilbith]

@gnumoksha u can do so manually by following this documentation. This is not done automatically by where-your-tmux-config-is.

[gnumoksha]

@weilbith this made the job, thanks!

One thing I would like to add is that someone can expect TMUX_PLUGIN_MANAGER_PATH to be changed according to $XDG_CONFIG_HOME.

[weilbith]

@gnumosksha
How do you expect that this works?
If TPM finds the tmux.conf inside $XDG_CONFIG_HOME directory, it should set $TMUX_PLUGIN_MANAGER_PATH to the same location automatically?

[dsifford]

Does this PR resolve the issue involving nonstandard tmux paths? (#57)

Can those of us who use tmux by calling it with tmux -f "$XDG_CONFIG_HOME"/tmux/tmux.conf, now use the newer set -g @plugin [...] syntax without issue?

Edit: Just tried and the answer is, yes we can.