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

Previous Next

Full log

Message #17 received at 76685 <at> debbugs.gnu.org (full text, mbox):

From: João Guerra <joca.bt <at> gmail.com>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 76685 <at> debbugs.gnu.org
Subject: Re: bug#76685: 30.1; custom--inhibit-theme-enable
Date: Fri, 7 Mar 2025 11:06:35 +0100

Thanks for the patch! It looks like a good conservative approach.


On Fri, 7 Mar 2025 at 10:26, Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>
> João Guerra <joca.bt <at> gmail.com> writes:
>
>  >> 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?
>  >
>  > That's the main use case indeed. Currently, the user needs to
>  > re-enable the theme after evaluating their custom-theme-set-faces. If
>  > they are experimenting with themes this becomes a bit cumbersome after
>  > a while. What I have been doing and seen in other configurations is
>  > `(setq custom--inhibit-theme-enable nil)`, so I was wondering if it
>  > would be desirable to expose this functionality somehow to the user.
>  >
>
> The attached patch adds support for this, but without exposing
> custom--inhibit-theme-enable, because it doesn't sound to me like a good
> idea.
>
> Opinions?

Previous Next

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