GNU bug report logs -
#76685
30.1; custom--inhibit-theme-enable
Previous Next
Reported by: João Guerra <joca.bt <at> gmail.com>
Date: Sun, 2 Mar 2025 14:11:02 UTC
Severity: normal
Tags: patch
Found in version 30.1
Fixed in version 31.1
Done: Mauro Aranda <maurooaranda <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76685 in the body.
You can then email your comments to 76685 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Sun, 02 Mar 2025 14:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
João Guerra <joca.bt <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 02 Mar 2025 14:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello, would it be possible to expose the functionality of
custom--inhibit-theme-enable as a user option, in some form?
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Tue, 04 Mar 2025 19:43:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 76685 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Wed, 05 Mar 2025 10:15:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76685 <at> debbugs.gnu.org (full text, mbox):
> 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.
On Tue, 4 Mar 2025 at 20:41, Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>
> 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.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Fri, 07 Mar 2025 09:27:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 76685 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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?
[0001-Allow-changing-theme-settings-without-reloading-it.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Fri, 07 Mar 2025 10:08:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 76685 <at> debbugs.gnu.org (full text, mbox):
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?
Added tag(s) patch.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 07 Mar 2025 10:15:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Fri, 07 Mar 2025 11:31:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 76685 <at> debbugs.gnu.org (full text, mbox):
> Cc: 76685 <at> debbugs.gnu.org
> Date: Fri, 7 Mar 2025 06:26:14 -0300
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> 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?
Since this has user-facing aspects, I think the effects of this change
should be called out in NEWS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Fri, 07 Mar 2025 11:48:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 76685 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/3/25 08:30, Eli Zaretskii wrote:
>> Cc: 76685 <at> debbugs.gnu.org
>> Date: Fri, 7 Mar 2025 06:26:14 -0300
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> 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?
>
> Since this has user-facing aspects, I think the effects of this change
> should be called out in NEWS.
Makes sense. Here's an updated patch.
[0001-Allow-changing-theme-settings-without-reloading-it.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Sun, 09 Mar 2025 10:25:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 76685 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 7 Mar 2025 08:47:20 -0300
> Cc: joca.bt <at> gmail.com, 76685 <at> debbugs.gnu.org
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> > Since this has user-facing aspects, I think the effects of this change
> > should be called out in NEWS.
>
> Makes sense. Here's an updated patch.
Thanks, LGTM.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76685; Package
emacs.
(Sun, 09 Mar 2025 12:28:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 76685 <at> debbugs.gnu.org (full text, mbox):
close 76685 31.1
quit
On 9/3/25 07:24, Eli Zaretskii wrote:
>> Date: Fri, 7 Mar 2025 08:47:20 -0300
>> Cc: joca.bt <at> gmail.com, 76685 <at> debbugs.gnu.org
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> > Since this has user-facing aspects, I think the effects of this
change
>> > should be called out in NEWS.
>>
>> Makes sense. Here's an updated patch.
>
> Thanks, LGTM.
Thanks. I installed the patch, and with that I'm closing this bug
report.
bug marked as fixed in version 31.1, send any further explanations to
76685 <at> debbugs.gnu.org and João Guerra <joca.bt <at> gmail.com>
Request was from
Mauro Aranda <maurooaranda <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 09 Mar 2025 12:28:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 07 Apr 2025 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 68 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.