[lmm]

> The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better?

Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI.

> You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.

Either of the first two is easier to work with than the XDG-compliant way, and the last is no harder.

[memetomancer]

FYI, and nothing personal, but your comment is more or less coming across to me as "whelp, the inflexible delegation has spoken".

I go to great lengths to maintain a flexible mindset, to try to get the best out of a new approach. Hearing/reading someone trying to throw a shallow take-down of something they haven't tried doesn't read as "ooh that person is so cool I'm super convinced"... it comes across more like "oh, poor fella went and got his brain rigidized... and at such a young age".

But maybe you'll come around. Maybe people will come around and realize the ankle-deep hot takes are worse than useless and we can all get back to the good stuff.

On the other hand, I do have my own suspicions. At first glance it does simply sound like another layer of idiosyncrasy to jam into the memory hole, something that will certainly never be universally adopted and just add more hidey-holes to search for config files.

But, as I hope I made clear, I'm willing to give it a shot because I don't trust myself to have absolute insight into a thing after a couple minutes reading. There may well be aspects to this that I can't conjure, but will really like after all is said and done.

[lmm]

> Hearing/reading someone trying to throw a shallow take-down of something they haven't tried

I mean, I've lived with XDG messing up where my config files are for several years at this point. How much "trying it" do I have to do to be allowed to have an opinion?

[chimprich]

> I mean, I've lived with XDG messing up where my config files are for several years

Why don't you set your XDG vars to where you want to put them then?

What's your alternative? Force everyone to follow your preference instead of having it configurable?

[rkta]

> Why don't you set your XDG vars to where you want to put them then?

I hear that argument often. When a program uses $XDG_CONFIG_HOME/tool/ for its config files, to what value should I set XDG_CONFIG_HOME to get the old behavior where it puts its config in $HOME/.tool/?

[chimprich]

That's an interesting question, and I don't know the answer. A Google search and ChatGPT request provide no answers, so this seems like an uncommon request. It seems like there ought to be a way to achieve this reasonable request though.

Possibly setting it to $HOME would make all/most programs assume that you wanted it to live in $HOME/.tool rather than $HOME/tool, but I'm guessing. I don't know if that's the standard.

[rkta]

I'm not sure it is so uncommon - just that there is no answer. I'm pretty convinced that a lot less people would complain about the XDG Base Directory Specification if that would be possible.

I'm one of those (though I usually do not publicly complain about it).

[yjftsjthsd-h]

> an overengineered, overly cumbersome hierarchy under that.

You put config files in $XDG_CONFIG_HOME/app/whatever with a fallback to $HOME/.config/app/whatever, and data files in $XDG_DATA_HOME/app/whatever with a fallback to $HOME/.local/share/app/whatever - what exactly is over engineered or cumbersome about that?