Using XDG_CONFIG_HOME or .config isn't right on mac

[nico]

XDG_CONFIG_HOME and .config are Linux-isms, or at least not-native-mac-app-isms.

https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1

The Library directory is where apps and other code modules store their custom data files.

Application Support Use this directory to store all app data files except those associated with the user’s documents. For example, you might use this directory to store app-created data files, configuration files,

The path to that can be accessed with FileManager.default.urls(for: .applicationSupportDirectory, in: .userDomainMask), it'll get a subdirectory based on the app bundle's CFBundleIdentifier (in Info.plist – com.mitchellh.ghostty for Ghostty.)

(https://developer.apple.com/documentation/foundation/nssearchpathdirectory/nsapplicationsupportdirectory?language=objc is the constant for "Application Support", https://developer.apple.com/documentation/foundation/nsfilemanager/1407693-urlfordirectory?language=objc has a code snippet.)

[mitchellh]

Thanks for opening a discussion on this @nico.

I'm in agreement that we should support the application support directory. I'm not 100% sure how yet (as in the semantics of it). So if we can figure that out in this discussion thread I'd be happy to convert to an issue and tag it appropriately.

Plenty of macOS software supports XDG directories too (usually cross-platform tools and not GUI tools). I think it'd be good for Ghostty to continue supporting it. So I think my main question is: what do we do if the user has a config file in both XDG and Application Support?

Ghostty supports config merging so we can load both, but then what order?

Any thoughts?

[mitchellh]

Yes I want to be clear that dropping support for XDG on macOS is not on the table for me. We will support XDG.

But id also like to support the app support dir.

[nico]

Plenty of macOS software supports XDG directories too

I'm guessing that's mostly software that started on Linux and that grew a Mac port. (I'm not saying that this can't be useful, e.g. if you want to sync config between a Mac and a Linux machine.)

For UI apps, I'd say that the "normal" way of doing prefs from a user point of view is to have a prefs window (I know there are plans for that) with "relatively" few prefs and good defaults, and defaults write support for some tweakables.

Having a prefs UI and a config file also has a similar problem: if both are changed at the same time, which one wins? I suppose changing a pref in the UI will immediately change the config file, and if users have that open in an editor, hopefully that'll live-reload?

Anyways, possible ideas:

• If .config file (well, file in .config/ or whatever the env vars points at if it's set) exists or comes into existence while running, try to merge it with settings in Application Support, diag if it doesn't match, then make the two files hard links of each other, to make sure they're in sync
• If .config file exists, always use it, else use one in Application Support. If settings in Application Support aren't the default settings and .config comes into existence, warn user that .config file is used while it's around.
• Load both, merge settings, warn on conflicts
• Your idea here

The second approach seems conceptually simplest, which is a point in its favor.

People who have a .config file will want that to be used, while people who don't have it probably prefer the native behavior.

[nico]

Another idea: once there's a prefs UI, have a toggle in there for where the prefs are stored (and store that once single setting as a user default instead of in the config file). Make it default to Application Support. That's easy to understand, the platform-appropriate default, and also easy to switch to an xdg location.

[mitchellh]

I think it'd be easiest to just choose one priority or the other and merge. I don't think we need to warn or detect conflicts or any of that (we don't have any easy/performant way to do that now anyways). I'm thinking of the following order where later values overwrite earlier:

1. Defaults (builtins)
2. XDG
3. Application Support

The thinking of this is that we go broadest to most specific: defaults apply to everyone, XDG is cross platform, app support is macOS specific.

[johnm]

Sounds reasonable to me.

[mitchellh]

Created #2634 to track this.