[SulphurCrested]

Towards the end TFA claims that Apple’s bundled command line utilities, including zsh and vim, put their dotfiles in ~/.config. They don’t. They put them in the traditional BSD place, the user’s home directory ~/. Looking at mine now, I see .bash_login, .emacs (wow! that’s old), .lldb, .lldbinit, .vimrc, .swiftpm, .z{profile,env,rc} and a few others. I see no ~/.config directory.

My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences, so they can interoperate with any GUI versions of them I might like to write, and for the utilities themselves to have command line options to control those settings. As a sibling comment suggests, you do need to avoid name space collisions. You can use a reverse DNS name, or some companies are big enough just to use their company name. They do appear as .plist files but are actually maintained by a daemon – which nicely avoids race problems with multiple processes updating settings.

If I were writing a portable utility which had a dotfile with a documented format the user was expected to edit, I would make it a dotfile under the home directory.

~/Library/Application Support is really more for per-user static data, like presets and templates, things that are known in a GUI by a string in some dialogue but not necessarily thought of by the user as a file.

[varenc]

> My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences

This would mean that essentially all edits to the configuration must be performed by the CLI tool itself? Because macOS preferences aren't really intended to be edited directly by the user. That feels like a totally different category of configuration than what we're discussing here. Though it certainly provides some nice functionality.

[SulphurCrested]

Yes, ideally the tool should edit its own preferences. A quick and dirty tool might leave the user to run the macOS "defaults" command line utility themselves. It’s certainly no worse than looking up the dotfile format and firing up vi.

[eviks]

In what world is this user hostile behavior ideal? There is no way you can write a cli tool that is more ergonomic in editing plain-texty config format than a good code editor!

> It’s certainly no worse

It's much worse, you don't get persistent undo from previous edits, indication of current changed and committed data, syntax highlighting, regex search, etc, etc.

[swiftcoder]

> It’s certainly no worse than looking up the dotfile format and firing up vi

It's a lot worse, IMO. We're all fluent in our text editor of choice, we all know the rough format conventions of dot files.

Whereas I'd certainly have to lookup man page of the defaults tool, and IIRC it only supports editing one-key-at-a-time, which sucks for a dense config file.

If your tool provides a TUI/GUI for editing preferences, that'd be a different story.

[linkage]

Yeah nah. If your configuration has a schema (e.g. JSON schema), AI tools can do a magnificent job turning free-form requests in natural language to valid configuration. Even if your configuration does not have a schema, people can refer to snippets of configuration made by other people on the internet.

Don't force your users to go through some custom sequence of CLI commands that they first have to spend 5 minutes learning. There should be no learning curve for a one-time setup.

[soraminazuki]

> I see no ~/.config directory.

Vim, Emacs, and Swift Package Manager do in fact support XDG. Also Git as well. But Vim doesn't create config files by itself and Emacs is no longer distributed by Apple.