[auto-dark] for emacs is now available on MELPA

Proud to announce another old package of mine is now available on MELPA. You define 2 themes one dark and one light, and emacs follows macOS global configuration for "dark-mode". Github: [https://github.com/LionyxML/auto-dark-emacs](https://github.com/LionyxML/auto-dark-emacs) I hope you find it useful.

Nice package! I've added support for this under Linux in my [init.el](https://github.com/andreyorst/dotfiles/blob/df57085f7d981f6dd16771d749f81d128d0fe965/.config/emacs/init.el) like this: (defun gnome-dark-mode-enabled-p () "Check if frame is dark or not." (if (executable-find "gsettings") (thread-last "gsettings get org.gnome.desktop.interface gtk-theme" shell-command-to-string string-trim-right (string-suffix-p "-dark'")) (eq 'dark (frame-parameter nil 'background-mode)))) (use-package dbus :straight nil :when window-system :requires (functions local-config) :config (defun gtk-theme-changed (path _ _) "DBus handler to detect when the GTK theme has changed." (when (string-equal path "/org/gnome/desktop/interface/gtk-theme") (if (gnome-dark-mode-enabled-p) (load-theme local-config-dark-theme t) (load-theme local-config-light-theme t)))) (dbus-register-signal :session "ca.desrt.dconf" "/ca/desrt/dconf/Writer/user" "ca.desrt.dconf.Writer" "Notify" #'gtk-theme-changed)) Works under GNOME Shell, haven't tried other DE/WMs. Maybe you could add support for Linux to your package like that, though it depends on dbus support.

I will repeat myself, it is highly undesirable to set the GTK theme env globally, or at any capability for this usecase. If you want this to happen properly, please bring this issue upstream, proper solutions consist of either - provide a method to set gtk-application-dark-mode programatically in the lisp part, so you just use the dbus code above in your config and apply that method when it corresponds - internally (at C level) read DBus and set gtk-application-dark-mode accordingly or maybe allow setting a hook on changes There is an issue open upstream where the devs suggest using libhandy, but it is a bad approach, not only libhandy is intended for GNOME projects and emacs would not benefit in any way from it, it is also adding a dependency which is not necessary and not available in any repository yet (1.6 is yet to be released). After all libhandy all it does is to read and listen to DBus and set gtk-application-dark-mode accordingly and this is what either emacs or the user have to do in their config... all that we are missing is a way of setting the GtkSetting for dark mode.

> I will repeat myself, it is highly undesirable to set the GTK theme env globally, or at any capability for this usecase. I'm not setting anything here.

Well anyways, the proper interface is org.freedesktop.portal.Settings. See https://github.com/hlissner/doom-emacs/issues/6027.

Looks nice, thanks for sharing! For those of us on the Mac Port, there's a hook we can use instead of polling: ;; Mac Port has `mac-do-applescript' instead of `ns-do-applescript' (setq auto-dark--allow-osascript t) (add-hook 'mac-effective-appearance-change-hook #'auto-dark--check-and-set-dark-mode)

I guess, because I use pgtk, I don't have to do anything to make menus and window border to follow system theme - it happens automatically. So my code above only changes the Emacs theme, bu subscribing to the dbus event, which, tbh seems like a proper approach.

I'm using this patch for Emacs. It uses system event instead of a timer: https://gist.github.com/ngquerol/33e099eceae527b368bdf196c95d1ba3

And thats the issue in fact you are not following the system theme but rather the gsetting for the Gtk theme, there is no such thing a system theme. The only proper and supported mechanism for dark mode is the xdg-desktop-portal backed setting which I discussed in the linked issue, this is *the* system preference for dark mode, or to be more precise the *user preference* and it is de-coupled from GTK themes. When distros start rolling the dark mode setting people will realize that their GTK themes inhibit and break the dark mode setting and many will opt to not use a theme. At that point your solution breaks because it is reading the GSetting that is no longer set on dark mode. On the other hand not all distributions care about GTK or gsettings, why would they have to read a gtk setting for a dark mode preference, maybe their system does not even support it for some reason. The dark mode user preference is DE/platform agnostic. Note that using PGTK actually makes things worse if you are on wayland since it is emacs drawing its own GtkHeaderBar rather than the server, emacs has to tell the compositor that it wants dark mode, and hence why it is important to have the GtkSetting::gtk-application-prefer-dark-mode key. server side decorations can eventually make the assumption to honor the user preference, on wayland you cannot do that. TL;DR it works for now, for you and not for others, and might not work tomorrow, and even then one could argue that it doesn't do what the user expects.

Thanks for in depth explanation, now I see your point clearly. FWIW for now I'm OK with my current approach, previously I had a separate tool that changed the theme using emacsclient, and it was way worse that what I have now.

Your approach is perfectly reasonable for your use case and specially for the time being where the dark mode setting is probably not supported (GNOME 42 will release next week with it for example). I just hope to produce a solution that scales for everyone.