Rather than reloading whatever `doom-theme` is set to, reload the
currently active theme(s). Although `load-theme` is advised to change
the value of `doom-theme`, not all theme switching commands use
`load-theme` (e.g. `consult-theme`).
Fix#5539
Emacs 27.x has been the stable version of Emacs for nearly a year, and
introduces a litany of bugfixes, performance, and quality-of-life
improvements that significantly reduce Doom's maintenance burden (like
XDG support, early-init.el, image manipulation without imagemagick, a
native JSON library, harfbuzz support, pdumper, and others).
With so many big changes on Doom's horizon, I like having one less (big)
thing to worry about.
Also reverts bb677cf7a (#5232) as it is no longer needed.
Trying to get 'doom to behave like 'user is too much trouble and causes
too many problems. The magic around 'user is too deeply woven into
custom.el. The whole custom.el fiasco needs to be dealt with another
way.
Fixes#5000Fixes#5009
This reverts commit cab8f03a51.
Urg, they did have to be macros, otherwise arguments are evaluated
immediately. Note to self, stop committing things after midnight.
Fixes#5015Closes#5016
Evaluating custom-set-faces! calls would add setter functions to
doom-load-theme-hook indefinitely, which could add up each time you M-x
doom/reload. Now it adds them to a subhook, which is reset whenever Doom
is reloaded.
custom--inhibit-theme-enable is non-nil by default in Emacs 27, which
inhibits uses of `custom-theme-set-faces` when modifying any theme other
than 'user.
If lexical-binding isn't enabled (with ';; -*- lexical-binding: t; -*-'
at the top of your private config), custom-set-theme! and
custom-theme-set-faces! throw this error. Since these macros are
commonly used in user configs, where I can't police lexical-binding,
I've refactored it to not rely on it.
