GNU bug report logs - #9373
23.3; [Themes] feature request: separate custom-enabled-themes user setting

Previous Next

Full log

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: 9373 <at> debbugs.gnu.org
Cc: Dave Abrahams <dave <at> boostpro.com>
Subject: Re: bug#9373: 23.3; [Themes] feature request: separate
 custom-enabled-themes user setting
Date: Mon, 17 Mar 2025 07:53:43 -0300

Dave Abrahams <dave <at> boostpro.com> writes:

> In my .emacs I am programmatically loading a theme based on system type,
> so it has to load a different file depending on the host system, but I
> also want to enable some other themes under "user control."
> Unfortunately, enabling a theme programmatically modifies the only
> customization variable I have, custom-enabled-themes, and I *don't* want
> to save that in my customizations that will be used on other systems.
> Of course I could remove the theme from that variable manually, but that
> seems like a hack; who knows whether the theme system relies on that
> variable today, or will tomorrow?

That's exactly what use-package does, which I agree is kind of ugly.

Doing that makes it impossible for disable-theme to disable the removed
theme, but maybe users of use-package never need to do that? But I
wonder if there any other use cases where it does matter.

> Ideally, there would be a way to enable a theme without altering the
> variable that says what themes should be enabled at startup.

Yes, maybe there could be a special keyword to pass when defining a
theme, to say that it shouldn't be added to custom-enabled-themes, but
that Custom still knows how to disable, reenable, etc.

Opinions?

Previous Next

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