GNU bug report logs - #76685
30.1; custom--inhibit-theme-enable

Previous Next

Full log

View this message in rfc822 format

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: João Guerra <joca.bt <at> gmail.com>, 76685 <at> debbugs.gnu.org
Subject: bug#76685: 30.1; custom--inhibit-theme-enable
Date: Tue, 4 Mar 2025 16:41:52 -0300

João Guerra <joca.bt <at> gmail.com> writes:

> Hello, would it be possible to expose the functionality of
> custom--inhibit-theme-enable as a user option, in some form?

Something like this has been discussed before:
https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00374.html

We don't act upon a call to custom-theme-set-faces immediately, to avoid
applying the theme's settings when loading it.  And it looks to me
that we don't want to make that customizable, since it's bad practice
for a package (theme or not) to have effects just because of loading it.

> The default behavior, where modifying a loaded and enabled theme
> requires re-enabling it to see the changes, may feel counterintuitive
> to some users.
>
> Allowing immediate visual feedback when evaluating
> custom-theme-set-faces would make theme customization easier.

So the use case would be:
The user already loaded and enabled a theme (via load-theme and
enable-theme) and then, while the theme is enabled, he/she wants to
reevaluate a custom-theme-set-faces and see its effect immediately?

Perhaps we can handle that use case by specializing
custom--should-apply-setting a bit more, without a need to expose
custom--inhibit-theme-enable.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.