Config file XDG conformance about xplr HOT 8 CLOSED

I'll try to look into this in the next couple of days. I actually raised a similar issue for rusmux (rust based tmuxinator alternative) since their config files are stored at ~/Library/Application\ Support/org.Meir-Kriheli-\<[email protected]\>.rusmux/ on MacOS even with XDG_CONFIG_HOME set.

Ideally we can find a library like dirs that actually honors the users config.

from xplr.

This would be a huge breaking change.
As far as my preference goes, ~/. config is the way to go for all CLI/TUI based tools, both on linux and bsd, including mac.
Could you pls confirm the OS you're using so that I can dig deeper into the issue?

from xplr.

linux. it would only be breaking for people who define XDG_CONFIG_HOME yet for some reason arent annoyed to hell when a program ignores it.

from xplr.

Sold. Can you pls create a fix?

from xplr.

@noahmayr said:

From what I understand this will break on MacOS. The dirs crate will give you MacOS specific paths like ~/Library/Application Support/xplr. Even though I'm explicitly setting $XDG_CONFIG_HOME, the maintainers of the dirs and directories crates are actively refusing to honor an environment variable intentionally set by MacOS users due to what sounds like "Apple knows best and it's your own fault for choosing a such a locked down system". Meanwhile 99% of CLI programs use ~/.config/* on MacOS or at least respect the $XDG_CONFIG_HOME environment variable.

@sayanarijit can we please hold back on releasing this until previous default behavior has been restored? This will be especially painful for those wanting to sync their dotfiles.

from xplr.

@noahmayr thanks for raising the concern.

I currently don't have access to a mac, so can't dig into it right now. But yes, I'm not releasing a new version without testing it on a mac.

from xplr.

There's this library we can try: https://whitequark.github.io/rust-xdg/xdg/struct.BaseDirectories.html

from xplr.

Closing this as fixed.

from xplr.