auto-dark only working when started after Emacs is loaded

[LionyxML]

Opening it as issue #19 follow up, since that was already closed.

@J3RN this discussion started after last #20 commit reached master. It might have something to do with the refactor but I can't look at it now :)

@manoeldeJesus said he needs to start emacs and THEN auto-dark, or it won't work.

@real-or-random said something specific to spacemacs distribution, I think we're not aware.

[manueldeljesus]

I have been following the code and I cannot find where the "error" may be, but as you mentioned, when I open Emacs, auto-dark does not load the correct theme, but if I deactivate auto-dark-mode and reactivate it, then it works and makes the theme change and everything.

My guess is that I am configuring it wrong, so I would appreciate if someone could share their configuration so that I can have a look to see if the problem is that one. It may be probably related to some other Doom Emacs configuration step that occurs after I load auto-dark, and that negatively interacts with my auto-dark configuration.

[real-or-random]

My guess is that I am configuring it wrong, so I would appreciate if someone could share their configuration so that I can have a look to see if the problem is that one.

There's not much going on in my config:

  (use-package auto-dark
    :init (auto-dark-mode t)
    :diminish auto-dark-mode
    :custom
    (auto-dark-light-theme 'solarized-light)
    (auto-dark-dark-theme 'solarized-dark))

It's supposed to work like this. Maybe doom's theming code gets similarly in the way (as spacemacs' theming code).

[real-or-random]

Well, it seems that this config suddenly works for me on spacemacs though I'm pretty sure I haven't changed anything since I had tested this when it didn't work. :tada:

I'm not exactly sure if there was something wrong with my config or if this is a random/timing issue... I'll report back here in case I see the issue again. :shrug:

[J3RN]

My config is also quite boring. I never knew about :custom, fancy!

(use-package auto-dark
  :config
  (setq auto-dark-light-theme 'adwaita)
  (auto-dark-mode 1))

[J3RN]

I'm a bit skeptical of :init (auto-dark-mode t) as it seems to conflict somewhat with use-package's README:

Use the :init keyword to execute code before a package is loaded. It accepts one or more forms, up to the next keyword:

(use-package foo
  :init
  (setq foo-variable t))

Similarly, :config can be used to execute code after a package is loaded. In cases where loading is done lazily (see more about autoloading below), this execution is deferred until after the autoload occurs:

(use-package foo
  :init
  (setq foo-variable t)
  :config
  (foo-mode 1))

(emphasis mine). That said, if it works for you, carry on! :grin:

[real-or-random]

@J3RN True. For some reason, :config doesn't work for me but this may be specific to spacemacs: https://github.com/nashamri/spacemacs-theme/issues/42#issuecomment-192128264

[manueldeljesus]

I found the problem: instead of calling (auto-dark-mode t) I was setting a variable with that name (setq auto-dark-mode t). Totally my bad. I apologize for the hassle.

I can confirm, thus, that the package works on Doom Emacs on Fedora 36 Gnome 42.4 without apparent problem.

Your help is really appreciated.

[real-or-random]

Okay, if it works for everyone, then we could close this issue.

[real-or-random]

I'm a bit skeptical of :init (auto-dark-mode t) as it seems to conflict somewhat with use-package's README:

I agree. I can't tell you why :init worked for me, but the README should recommend :config, in particular, if we know that it works for you.

After upgrading some packages in spacemacs, it broke again for me. The problem is really that spacemacs also tries to set themes on startup, and this happens after all the user config, so it overrides whatever auto-dark-mode has set before. I've arrived at this solution:

(use-package auto-dark
    :init
    (spacemacs/defer-until-after-user-config (lambda () (auto-dark-mode t)))
    :defer t)

Note that :init is okay here, because (auto-dark-mode t) is not run, but only added to a hook. Then loading is deferred, so the following happens (which I have verified by debugging:.

• the above code does not load auto-dark, but registers it for autoload
• then it adds (auto-dark-mode t) to a hook run after the user config
• then spacemacs loads a theme according to its settings
• then spacemacs calls the hook, which finally runs (auto-dark-mode t) (which involves autoloading auto-dark beforehand)

This is not ideal because loading a theme and then a different theme will waste time, but at least that works consistently on spacemacs. Maybe I'll propose full integration to spacemacs, but that's a bit more work.

I'm happy to open a PR to make these changes in the README.

[LionyxML]

I think this PR should be really appreciated for Spacemacs users.

[tasmo]

For Doom I got it working perfectly adding

in package.el:

(package! auto-dark)

and in config.el:

(defun my-auto-dark-hook ()
  (setq! auto-dark-dark-theme  'humanoid-dark
         auto-dark-light-theme 'humanoid-light)
  (auto-dark-mode 1))
(add-hook! 'doom-load-theme-hook #'my-auto-dark-hook)

[real-or-random]

I also switched to doom recently, and I use this, which also works nicely in daemon mode:

(setq! doom-theme nil)
(use-package! auto-dark
  :defer t

  :init
  (setq! auto-dark-dark-theme  'doom-solarized-dark
         auto-dark-light-theme 'doom-solarized-light)

  ;; Inspired by doom-ui.el.
  ;; Note that server-after-make-frame-hook also avoids the issues with an early
  ;; start of the emacs daemon using systemd, which causes problems with the
  ;; DBus connection that auto-dark mode relies upon.
  (let ((hook (if (daemonp)
                  'server-after-make-frame-hook
                'after-init-hook)))
    ;; Depth -95 puts this before doom-init-theme-h, which sounds like a good
    ;; idea, if only for performance reasons.
    (add-hook hook #'auto-dark-mode -95)))

Happy to PR this too, after I had also authored the spacemacs instructions. :D