feat: adds basic support for XDG dirs

[higherorderfunctor]

Adds some additional control over the config and init file locations.

When installed with an immutable/declarative OS, the plugin directory is read-only.

Could probably use some more rigid assignments of those paths for full XDG support (see the discussion at tmux-plugins/tmux-resurrect#348).

When I get a moment, I can dig in some more, but for now I wanted to share some minimal changes that make this plugin usable with Nix.

[higherorderfunctor]

Cleaned up the error handling and added another option to control the path after XDG_*_HOME.

[higherorderfunctor]

Fixes #2.

[alexwforsythe]

Thanks for the PR! Looks good overall, just a few questions before we move forward

[alexwforsythe]

Suggested change

	The allows the plugin to also be used with immutable or declarative operating
	This allows the plugin to also be used with immutable or declarative operating

[higherorderfunctor]

Typo on my part. I can make this change. I'll get that in within a day or two.

[higherorderfunctor]

Updates made. Reworded a few things, so let me know if this works.

[alexwforsythe]

I didn't read the XDG spec, but my understanding from the issue you linked is we should default to $HOME/.local/share if XDG_DATA_HOME is unset, instead of returning an error. Should we change this behavior?

Same comment for XDG_CONFIG_HOME if the spec defines a fallback for that dir

[higherorderfunctor]

Yes, I can make this change.

[higherorderfunctor]

Changes made. Added a function make_xdg_path to follow the spec which states:

If, when attempting to write a file, the destination directory is non-existent an attempt should be made to create it with permission 0700. If the destination directory exists already the permissions should not be changed.

I did add a dependency of realpath to avoid that function from creating a bunch of directories that could be caused with a bad relative path. If you would like to remove it, I can.

[alexwforsythe]

Does the spec say to return an error if an XDG dir doesn't exist? I ask because it seems possible to just mkdir -p it if missing. No strong opinion either way

[higherorderfunctor]

I was being overly cautious, but I can make this change.

Yes, we can create the directory. It does involve a little extra work. I am thinking the basic flow is:

• If it exists, use it.
• If it doesn't, create it with 0700.
• Raise an error if for some reason these directories are not writeable or cannot be created.

[higherorderfunctor]

The spec states:

The application should be prepared to handle the case where the file could not be written, either because the directory was non-existent and could not be created, or for any other reason. In such case it may choose to present an error message to the user.

With the earlier changes to use a default directory and create all paths that do not exist so long as they are contained in $HOME, this error would then be generated by mkdir -p in the new code. In the existing code it would be generated by cp which is where it errors now with Nix.

[higherorderfunctor]

Thanks for the PR! Looks good overall, just a few questions before we move forward

I can make the requested changes over the next day or two. I'll comb through the full spec to look for any nuances that may need to be considered. Here is the link to the actual spec: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html.

[higherorderfunctor]

Changes have been made. Let me know if these work. Thanks for the feedback.