it is the correct path for application data. Configs go in ~/.config on Linux, ~/Library/Application Support on Mac, and ~\AppData\Roaming on Windows; some other tools doing the wrong thing isn't a reason for nushell to do the wrong thing, and your preference for nushell doing the wrong thing shouldn't mean I have to suffer it. If you want it to be visible in your home dir, you can easily put a symlink there.

When you work on multiple OSes (mainly macOS and Linux), having your dot files normalized is IMHO the best experience, yes, I have symlinked, but if I need to setup a new mac (that does not happen often) then I could forgot about it and will take an extra step to setup, as I said that's just my preference.

Also I want to say that the ~/Library/Application Support directory only works good for desktop app, so it's easy to get rid of the configurations of an app that you want to uninstall (I use AppCleaner), but terminal apps you install most likely by a curl|bash or brew, so there's no point on using that directory IMHO, to me feels that the maintainers are not mac users so they don't care on improving that, for me, is a pain point.

But that does not take the merit of nushell, from all the other new ones (fish, oil, etc) I think is the one that I enjoyed the most.

iterm2 puts config in ~/.config, while also having a directory in ~/Library/Application\ Support/ (habit). The author of iTerm has more credibility than the person you're replying to imho.

If a program is putting text files a user is supposed to edit in that directory, that's a mistake. If the application doesn't live in ~/Applications and provide a GUI for editing configuration, the file belongs in ~/.config and the app should follow XDG standards in general.

The XDG standard is a Linux standard, for compatibility between Linux distributions. Writing to ${XDG_CONFIG_HOME:-~/.config} on a non-Linux platform is like writing to ${APPDATA:-~/AppData/Roaming} on a non-Windows platform. I will never understand where the habit of assuming Linux standards are universal standards comes from.

There is nothing in Apple's documentation about Application Support being incorrect for CLI applications. It is an ex post facto justification for apps that do the wrong thing on Linux too and don't want to go to the effort. They are almost guaranteed to do the same thing on Windows and not even go to the effort of setting the folder as hidden.

That's just, like, your opinion, man.

It's also objectively Wrong, the X stands for X Windows, what you are referring to as Linux is actually ABunchOfStuff/Linux, or as I've recently started calling it, ABunchOfStuff+Linux. macOS has an X server, still, to this day.

It's also pragmatically wrong, there are more than a dozen directories in my ~/.config directory. Be the old man yelling at the cloud all you want, or, maybe, follow the available standard like other sane, polite programs.

The nice thing about XDG? Just point XDG_CONFIG_HOME and XDG_DATA_HOME at Application\ Support if you want stuff to show up there. A program which doesn't check for those flags is not supporting the standard, file a bug.

So, to repeat myself: use XDG. That's what it's there for.

And the D stands for Desktop, and no platforms other than GNU/Linux, or as I've taken to calling it, Linux, use X for the DE. It is a Linux standard. Specifically, the role the XDG spec plays on Linux is the role that the official documentation plays on Mac and Windows: to define where well-behaved programs should place their files. The consequences of ignoring it on Linux are the same as ignoring the official guidelines on Mac or Windows, as is the Correctness(tm). If you ignore it on Linux, your program is not well-behaved, and if you follow it on Mac and ignore Apple's official guidelines, your program is not well-behaved. Pointing out many instances of bad behavior does not make behavior less bad.

This specifically breaks down on Windows. The purpose of sticking dotfolders in $HOME is because you can't see them so they don't clutter your user folder, but they're also not hard to find. One of three things must be true:

1. The universal value is in them being hidden, so a program should go out of its way to hide them on Windows, and thus have platform specific code, despite not having a platform specific directory.

2. The universal value is in them not requiring platform specific code (other than maybe checking $USERPROFILE instead of $HOME), so a program should not bother hiding them on Windows, despite this resulting in a user folder with more junk folders than meaningful folders.

3. The whole concept doesn't translate very well to Windows, being a Linux standard designed for Linux. Windows software should be written to conform to Windows standards.

The answer is very clearly 3, and it is no great leap from there to notice that Mac is the same way. It is also no great leap to notice that not a single program that stores stuff in ~/.config on Mac pays the least bit of notice to XDG variables. Your declaration of it being a de facto standard falls completely flat on that point alone: well written software hardcodes ~/Library unless XDG_CONFIG_HOME is defined, poorly written software unconditionally hardcodes ~/.config, no Mac software that I have ever seen hardcodes ~/.config but listens to $XDG_CONFIG_HOME. So it is not standard outside of Linux. What is standard for Linux software, especially cross-platform ports of Linux software, is total abject laziness on the subject of well-behavedness.

surely something as basic as the location of the config folder can somehow be changed to a custom path, right?

Configuring where configuration data lives can be tricky. (Chicken/egg problem.)

But you can certainly create your own symlink.

Yeah, the issue is mainly if you setup a new machine with your dot files, you need to remember to setup the symlink, because you don't do that so often is so easy to forgot. Also I pointed that out because I share my dot files between Mac and Linux and that's certainly annoying to have two paths for both.