Kitty: ~/.config/kitty/kitty.conf on macos

[thomasjachmann]

Is there a specific reason the xdg config location isn't checked on macos? Quite a lot of tools also use this on macos and I really like to move my text based configuration files there whenever possible.

[kovidgoyal]

XDG is freedesktop specific. The canonical location for preferences on macOS is ~/Library/Preferences. kitty respects platform conventions wherever possible.

[thomasjachmann]

My point wasn't that you should replace ~/Library/kitty but that you could check both locations. This isn't contrary to de facto platform conventions since quite a lot of tools allow to use ~/.config to store their configurations on macos, especially cross platform tools like git, vim, zsh, darktable, Fritzing to name a few.

Concerning official platform conventions: As far as I understand the macos preferences system, the canonical location of the kitty preferences should actually be ~/Library/Preferences/com.kovidgoyal.kitty.plist along with using the binary property list format instead of a text file. This is not desirable.

[kovidgoyal]

I see absolutely no reason to check multiple places, it just creates confusion and extra things to check when debugging. If you want to use ~/.config, use it and create a symlink in ~/Library/Preferences

[neverfox]

~/Library/Preferences/com.kovidgoyal.kitty.plist along with using the binary property list format instead of a text file. This is not desirable.

Right. Kitty is literally the only application on my machine that is expecting a text conf file in Library/Preferences (where everything else there is a binary property list file). Plenty of OS X versions of Unix apps use the same location as one would expect on a Linux box. That itself creates confusion and extra things to do for the user.

├── com.runningwithcrayons.Alfred-3.plist
├── com.runningwithcrayons.Alfred-Preferences-3.plist
├── com.sonos.macController.plist
├── com.surteesstudios.Bartender.plist
├── com.tinyspeck.slackmacgap.helper.plist
├── com.tinyspeck.slackmacgap.plist
├── google-play-music-desktop-player.helper.plist
├── google-play-music-desktop-player.plist
├── kitty
│   └── kitty.conf
├── loginwindow.plist
├── net.15cm.AMM.plist
├── net.tunnelblick.tunnelblick.plist
├── org.gnu.Emacs.plist
├── org.gpgtools.gpgkeychain.plist
├── org.gpgtools.updater.plist
├── org.herf.Flux.plist
├── org.pqrs.Karabiner-Elements-Updater.plist
└── org.pqrs.Karabiner-Menu.plist

I see absolutely no reason to check multiple places, it just creates confusion and extra things to check when debugging.

Fair enough, but doesn't supporting two possibilities by OS create extra things to debug? I realize you would have a backwards compatibility issue on your hands, but I think that if you want to support platform conventions, that might be a bullet you have to bite.

If you want to use ~/.config, use it and create a symlink in ~/Library/Preferences

For me (and probably others), It's as much about not having it in ~/Library/Preferences as it is about having it in ~/.config. I do appreciate having the KITTY_CONFIG_DIRECTORY or --config option for that reason.

[kovidgoyal]

Umm just create a symlink in ~/Library/Preferences to ~/.config kitty. And no supporting two places by OS does not create extra things to debug having multiple places to read config files from does. What the single place a config file is read from is does not matter, as long as it is a single place.

[neverfox]

I think perhaps I wasn't clear about why that is neither ideal nor respecting platform conventions. I don't want a symlink in ~/Library/Preferences. I don't want anything in that folder that isn't a .plist file. As the example tree above shows, a text conf file (or a symlink to one) is out of place there. My solution for that at the moment is using the environment variable to change the expected location.

As for the debugging comment, what I mean is that every line of code or branch of logic is a possible bug. You have lines of code dedicated to checking the OS that wouldn't be necessary if you used only the XDG convention. I'm not suggesting supporting multiple places, unlike @thomasjachmann. I'm suggesting one: the XDG convention. Of course, the horse is already out of the stable and as an application developer you have backwards compatibility issues to consider. I understand it's not a frictionless option and I'm content with just continuing to use the environment variable to keep my Library/Preferences folder clean.

In any case, thanks for kitty. Great terminal!