GNU bug report logs -
#79696
[wishlist] Make (some) built-in themes be built on top of Modus themes
Previous Next
To reply to this bug, email your comments to 79696 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Sat, 25 Oct 2025 19:46:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Elijah Gabe Pérez <eg642616 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 25 Oct 2025 19:46:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[ Hello, i'm starting this for when modus-themes 4.8.1
arrives to emacs git. ]
Some themes included in Emacs are not entirely complete, and usually
most faces are lost in these themes.
The way I have found to solve this is to rewrite the themes on top of
modus-themes.
Having modus themes as a basis ensures that all the faces supported by
it, are not lost in the created theme and with the respective colors of
the new theme, this adds better visual consistency.
Here is a screenshot of the wombat theme (modified by me, it's not
complete yet) using modus as base:
[with-modus.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via Gnus and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Sat, 25 Oct 2025 19:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79696 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Oct 25, 2025 at 3:46 PM Elijah Gabe Pérez <eg642616 <at> gmail.com>
wrote:
> [ Hello, i'm starting this for when modus-themes 4.8.1
> arrives to emacs git. ]
>
> Some themes included in Emacs are not entirely complete, and usually
> most faces are lost in these themes.
>
> The way I have found to solve this is to rewrite the themes on top of
> modus-themes.
>
> Having modus themes as a basis ensures that all the faces supported by
> it, are not lost in the created theme and with the respective colors of
> the new theme, this adds better visual consistency.
>
It's a good idea. Prot's contributions via modus-themes (and its sister
themes like ef-themes) are excellent starting points and he's taken a lot
of care to ensure excellent coverage for Emacs built-ins and also a number
of very popular packages.
Whenever I see people discuss some custom theme or other in the wild, I
encourage them to do the same thing: theme modus instead of
purely standalone. If I found a theme in the wild that was modus based, I'd
be way more likely to try it than not.
-Stéphane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Sat, 25 Oct 2025 21:01:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Stéphane Marks <shipmints <at> gmail.com> writes:
> It's a good idea.
Yes!
> Prot's contributions via modus-themes (and its sister
> themes like ef-themes) ...
Also Doric themes are great (I use Water and Obsidian). Prot is now
rebasing all of his themes on Modus [1], and I hope to see Ef and Doric
built into Emacs one day, following Modus.
[1] https://protesilaos.com/codelog/2025-10-01-emacs-modus-framework-ef-built-on-top/
Rudy
--
"'Obvious' is all too often a synonym for 'wrong'."
--- Jeff Erickson, Algorithms, 2019
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Sun, 26 Oct 2025 07:29:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Hello folks,
> From: Stéphane Marks <shipmints <at> gmail.com>
> Date: Sat, 25 Oct 2025 15:52:45 -0400
>
> On Sat, Oct 25, 2025 at 3:46 PM Elijah Gabe Pérez <eg642616 <at> gmail.com>
> wrote:
>
>> [ Hello, i'm starting this for when modus-themes 4.8.1
>> arrives to emacs git. ]
This will actually be version 5.0.0 of the modus-themes. I believe I am
done with the development work and will check for any remaining issues.
I might make a release in the coming week.
>> Some themes included in Emacs are not entirely complete, and usually
>> most faces are lost in these themes.
>>
>> The way I have found to solve this is to rewrite the themes on top of
>> modus-themes.
>>
>> Having modus themes as a basis ensures that all the faces supported by
>> it, are not lost in the created theme and with the respective colors
>> of
>> the new theme, this adds better visual consistency.
>>
>
> It's a good idea. Prot's contributions via modus-themes (and its
> sister
> themes like ef-themes) are excellent starting points and he's taken a
> lot
> of care to ensure excellent coverage for Emacs built-ins and also a
> number
> of very popular packages.
I could try this, but I will not make any promises. Firstly, I do not
use those other themes and do not have a good intuition of what works
and what does not work for them. Secondly, I cannot tell how much time
it would even take me. Thirdly, it is hard to change themes in such a
thoroughgoing way without upsetting their existing users---I would
rather not have to deal with the resulting back-and-forth for a project
I do not maintain.
All the best,
Prot
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Sun, 26 Oct 2025 07:35:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 79696 <at> debbugs.gnu.org (full text, mbox):
> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Date: Sat, 25 Oct 2025 23:00:38 +0200
> [... 7 lines elided]
>> Prot's contributions via modus-themes (and its sister
>> themes like ef-themes) ...
>
> Also Doric themes are great (I use Water and Obsidian). Prot is now
> rebasing all of his themes on Modus [1],
>
> [1]
> https://protesilaos.com/codelog/2025-10-01-emacs-modus-framework-ef-built-on-top/
The doric-themes will remain their own thing, at least for the time
being. The way I handle things there is very different to how I do it
with the modus-themes. Though, yes, the ef-themes and standard-themes
are already built on top of Modus. I will publish the new major versions
in the coming days.
That blog post will eventually be out-of-date. The source for interested
parties is the manual of the Modus themes, specifically this section:
<https://protesilaos.com/emacs/modus-themes#h:86eb375b-9be4-43ce-879a-0686a524a63b>.
> and I hope to see Ef and Doric built into Emacs one day, following
> Modus.
I am fine if this happens, though it is not my decision to make. The
themes being available on GNU ELPA is already helpful and I have a good
time working on them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Sun, 26 Oct 2025 17:19:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Protesilaos Stavrou <prot <at> protesilaos.com> writes:
>>> [ Hello, i'm starting this for when modus-themes 4.8.1
>>> arrives to emacs git. ]
>
> This will actually be version 5.0.0 of the modus-themes. I believe I
> am
> done with the development work and will check for any remaining
> issues.
> I might make a release in the coming week.
Great, thank you for all the work you've done in modus-themes.
[...]
>> It's a good idea. Prot's contributions via modus-themes (and its
>> sister
>> themes like ef-themes) are excellent starting points and he's taken
>> a lot
>> of care to ensure excellent coverage for Emacs built-ins and also a
>> number
>> of very popular packages.
>
> I could try this, but I will not make any promises. Firstly, I do not
> use those other themes and do not have a good intuition of what works
> and what does not work for them. Secondly, I cannot tell how much time
> it would even take me. Thirdly, it is hard to change themes in such a
> thoroughgoing way without upsetting their existing users---I would
> rather not have to deal with the resulting back-and-forth for a
> project
> I do not maintain.
Well, I was actually willing to do this (at least for a few), I
currently have the wombat theme rewritten using modus.
I don't know if the other theme maintainers (and their users) agree with
this idea, but I think it would be worth it, it would be the closest we
would have to ef-themes and standard-themes in core.
What I find complicated is creating the appropriate color palette for
each theme.
--
- E.G via GNU Emacs Android port.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Sun, 26 Oct 2025 20:52:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:
> [ Hello, i'm starting this for when modus-themes 4.8.1
> arrives to emacs git. ]
>
> Some themes included in Emacs are not entirely complete, and usually
> most faces are lost in these themes.
>
> The way I have found to solve this is to rewrite the themes on top of
> modus-themes.
A suggestion I have made in the past was to identify the features in a
theme like modus-themes uses and then add the necessary semantic faces
to the core, that most packages have to re-invest. I sadly never got
around to doing this, but it seems like in the long-term ensuring that
the built-in faces are sufficient for most themes would scale better
than having to manually tail them in a large theme like modus themes.
> Having modus themes as a basis ensures that all the faces supported by
> it, are not lost in the created theme and with the respective colors of
> the new theme, this adds better visual consistency.
>
> Here is a screenshot of the wombat theme (modified by me, it's not
> complete yet) using modus as base:
>
> x
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Mon, 27 Oct 2025 05:39:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79696 <at> debbugs.gnu.org (full text, mbox):
> From: "Elijah G." <eg642616 <at> gmail.com>
> Date: Sun, 26 Oct 2025 11:18:43 -0600
>
> Protesilaos Stavrou <prot <at> protesilaos.com> writes:
>
>>>> [ Hello, i'm starting this for when modus-themes 4.8.1
>>>> arrives to emacs git. ]
>>
>> This will actually be version 5.0.0 of the modus-themes. I believe I
>> am done with the development work and will check for any remaining
>> issues. I might make a release in the coming week.
>
> Great, thank you for all the work you've done in modus-themes.
You are welcome!
> [... 10 lines elided]
>> I could try this, but I will not make any promises. Firstly, I do not
>> use those other themes and do not have a good intuition of what works
>> and what does not work for them. Secondly, I cannot tell how much
>> time it would even take me. Thirdly, it is hard to change themes in
>> such a thoroughgoing way without upsetting their existing users---I
>> would rather not have to deal with the resulting back-and-forth for a
>> project I do not maintain.
>
> Well, I was actually willing to do this (at least for a few), I
> currently have the wombat theme rewritten using modus.
>
> I don't know if the other theme maintainers (and their users) agree
> with this idea, but I think it would be worth it, it would be the
> closest we would have to ef-themes and standard-themes in core.
If people are okay with it, then I am fine too. And I am happy to help
however I can.
> What I find complicated is creating the appropriate color palette for
> each theme.
This is the most difficult part because to make the colours look right
you need to have a good sense of the existing style. It is why I do not
have the intuitions right now. But I can give it a try and eventually be
in a position to make suggestions. This is how I ended up with the
standard-themes, for example.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Tue, 28 Oct 2025 03:06:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
[...]
> A suggestion I have made in the past was to identify the features in a
> theme like modus-themes uses and then add the necessary semantic faces
> to the core, that most packages have to re-invest. I sadly never got
> around to doing this, but it seems like in the long-term ensuring that
> the built-in faces are sufficient for most themes would scale better
> than having to manually tail them in a large theme like modus themes.
I think it's also a good idea, however I'm not sure if this will ensure
that other third-party faces can also be supported, Modus already
supports a large number of these. Also, basing it on modus will give us
a better customization for each theme, so for the moment I think using
modus would be the solution, however, I wish creating themes was as
effective as Modus.
--
- E.G via GNU Emacs Android port.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Tue, 28 Oct 2025 03:25:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Protesilaos Stavrou <prot <at> protesilaos.com> writes:
>
> If people are okay with it, then I am fine too. And I am happy to help
> however I can.
>
Great, so if there are no objections (and after Modus 5.0.0 arrives), I
can start rewriting a few (wombat and adwaita) to see how well they
would be accepted.
--
- E.G via GNU Emacs Android port.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Tue, 28 Oct 2025 08:05:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Can you clarify what your concern is? I agree that in the short term rebasing all themes on Modus would be faster, but the theme is relativly heavyweight and specifies faces for a number of packages that are not even in ELPA. My hope is that by adding more semantic faces to the core (that we can backport using Compat), that we can at least convince larger packages to adopt these and suggest it to all new additions to ELPA as well. The consequence is that it should be easier for everyone to creat themes, as ideally you wouldn't have to care about custom faces defined just by one theme. This is assuming that the large number of faces that packages define is a symptom of a real need to express _semantic_ qualities visually, that the core is not supplying presently. If I am correct, this would also help towards creating more consistent semantic user interfaces, even for little scripts that are not on ELPA or thr Modus Themes know about.
On 28 October 2025 04:05:30 CET, "Elijah G." <eg642616 <at> gmail.com> wrote:
>Philip Kaludercic <philipk <at> posteo.net> writes:
>
>[...]
>
>> A suggestion I have made in the past was to identify the features in a
>> theme like modus-themes uses and then add the necessary semantic faces
>> to the core, that most packages have to re-invest. I sadly never got
>> around to doing this, but it seems like in the long-term ensuring that
>> the built-in faces are sufficient for most themes would scale better
>> than having to manually tail them in a large theme like modus themes.
>
>I think it's also a good idea, however I'm not sure if this will ensure
>that other third-party faces can also be supported, Modus already
>supports a large number of these. Also, basing it on modus will give us
>a better customization for each theme, so for the moment I think using
>modus would be the solution, however, I wish creating themes was as
>effective as Modus.
>
Sent from my phone
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Wed, 29 Oct 2025 04:01:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
> Can you clarify what your concern is?
My concern is to prevent these themes from becoming
unmaintained/obsolete, I'm not sure if they are really actively
maintained, since there are already many built-in faces that are not
supported by them (e.g. tab-line/bar faces are not themed), which
generates visual inconsistencies and make it look ugly. It would be
better to find an easier way to make these themes more visually
appealing and complete.
> I agree that in the short term
> rebasing all themes on Modus would be faster, but the theme is
> relativly heavyweight and specifies faces for a number of packages
> that are not even in ELPA. My hope is that by adding more semantic
> faces to the core (that we can backport using Compat), that we can at
> least convince larger packages to adopt these and suggest it to all
> new additions to ELPA as well. The consequence is that it should be
> easier for everyone to creat themes, as ideally you wouldn't have to
> care about custom faces defined just by one theme. This is assuming
> that the large number of faces that packages define is a symptom of a
> real need to express _semantic_ qualities visually, that the core is
> not supplying presently. If I am correct, this would also help
> towards creating more consistent semantic user interfaces, even for
> little scripts that are not on ELPA or thr Modus Themes know about.
I agree, maybe do something similar to what autothemer and Modus do,
define a color palette that each theme can modify individually, This
would prevent many faces from having to inherit from many others.
But I would like to know if Prot also has any ideas on how this can be
improved.
--
- E.G via GNU Emacs Android port.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Thu, 30 Oct 2025 22:31:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 79696 <at> debbugs.gnu.org (full text, mbox):
"Elijah G." <eg642616 <at> gmail.com> writes:
> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Can you clarify what your concern is?
>
> My concern is to prevent these themes from becoming
> unmaintained/obsolete,
Where "these themes" are the remaining non-modus based, built-in themes,
right?
> I'm not sure if they are really actively
> maintained, since there are already many built-in faces that are not
> supported by them (e.g. tab-line/bar faces are not themed), which
> generates visual inconsistencies and make it look ugly. It would be
> better to find an easier way to make these themes more visually
> appealing and complete.
Officially they should all be maintained. Themes like light-blue, that
were officially unmaintained were marked as deprecated, for instance.
But one should also be careful not to change too much. I already find
the change from the actual default non-theme to the current modus-based
standard-themes too much, and as beauty is in the eye of the beholder,
we should be careful not to introduce too many unnecessary changes.
>
>> I agree that in the short term
>> rebasing all themes on Modus would be faster, but the theme is
>> relativly heavyweight and specifies faces for a number of packages
>> that are not even in ELPA. My hope is that by adding more semantic
>> faces to the core (that we can backport using Compat), that we can at
>> least convince larger packages to adopt these and suggest it to all
>> new additions to ELPA as well. The consequence is that it should be
>> easier for everyone to creat themes, as ideally you wouldn't have to
>> care about custom faces defined just by one theme. This is assuming
>> that the large number of faces that packages define is a symptom of a
>> real need to express _semantic_ qualities visually, that the core is
>> not supplying presently. If I am correct, this would also help
>> towards creating more consistent semantic user interfaces, even for
>> little scripts that are not on ELPA or thr Modus Themes know about.
>
> I agree, maybe do something similar to what autothemer and Modus do,
> define a color palette that each theme can modify individually, This
> would prevent many faces from having to inherit from many others.
Crucially, I am not proposing a colour-palette, but faces with semantic
meanings. We already have a few like `warning', `success', `match',
`highlight', `shadow', and the question would be to find reasonable
candidates to add as well.
> But I would like to know if Prot also has any ideas on how this can be
> improved.
I believe he and I have wrote about this before, but it slipped under my
radar since then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Mon, 03 Nov 2025 02:49:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
> Where "these themes" are the remaining non-modus based, built-in themes,
> right?
Yes.
>> I'm not sure if they are really actively maintained, since there are
>> already many built-in faces that are not supported by them
>> (e.g. tab-line/bar faces are not themed), which generates visual
>> inconsistencies and make it look ugly. It would be better to find an
>> easier way to make these themes more visually appealing and complete.
>
> Officially they should all be maintained. Themes like light-blue, that
> were officially unmaintained were marked as deprecated, for instance.
>
> But one should also be careful not to change too much. I already find
> the change from the actual default non-theme to the current modus-based
> standard-themes too much, and as beauty is in the eye of the beholder,
> we should be careful not to introduce too many unnecessary changes.
Yes, probably the mechanism that modus uses to create themes should be
independent, by default customizing only some core faces that do not
inherit from any other and avoiding opinionated customizations that
perhaps not many themes would prefer.
>> I agree, maybe do something similar to what autothemer and Modus do,
>> define a color palette that each theme can modify individually, This
>> would prevent many faces from having to inherit from many others.
[...]
> I believe he and I have wrote about this before, but it slipped under my
> radar since then.
Well then, I should better contribute the themes I already have to
standard-themes.
--
- E.G via Gnus and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Mon, 03 Nov 2025 22:04:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:
> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Where "these themes" are the remaining non-modus based, built-in themes,
>> right?
>
> Yes.
>
>>> I'm not sure if they are really actively maintained, since there are
>>> already many built-in faces that are not supported by them
>>> (e.g. tab-line/bar faces are not themed), which generates visual
>>> inconsistencies and make it look ugly. It would be better to find an
>>> easier way to make these themes more visually appealing and complete.
>>
>> Officially they should all be maintained. Themes like light-blue, that
>> were officially unmaintained were marked as deprecated, for instance.
>>
>> But one should also be careful not to change too much. I already find
>> the change from the actual default non-theme to the current modus-based
>> standard-themes too much, and as beauty is in the eye of the beholder,
>> we should be careful not to introduce too many unnecessary changes.
>
> Yes, probably the mechanism that modus uses to create themes should be
> independent, by default customizing only some core faces that do not
> inherit from any other and avoiding opinionated customizations that
> perhaps not many themes would prefer.
But wouldn't this effectively simplify down to just having a regular
theme? BTW you could also take my proposal to merge the changes
introduced by Modus Themes deeper into Emacs' theme system (merging
changes that would make general sense to have into the core), instead of
having to build themes on-top of other themes.
>>> I agree, maybe do something similar to what autothemer and Modus do,
>>> define a color palette that each theme can modify individually, This
>>> would prevent many faces from having to inherit from many others.
>
> [...]
>
>> I believe he and I have wrote about this before, but it slipped under my
>> radar since then.
>
> Well then, I should better contribute the themes I already have to
> standard-themes.
I am confused, what themes do you mean?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Mon, 03 Nov 2025 23:50:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 79696 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
> But wouldn't this effectively simplify down to just having a regular
> theme?
Probably, but many of these non-modus themes does not support some
built-in faces (e.g. minibuffer-nonselected).
Perhaps it would be better to add those missing (core) faces to each of
these themes, it would work for a while, but when more unique faces are
added to core, it will be difficult to maintain.
I will see what i can do about this.
> BTW you could also take my proposal to merge the changes introduced by
> Modus Themes deeper into Emacs' theme system (merging changes that
> would make general sense to have into the core), instead of having to
> build themes on-top of other themes.
Yes, but i think it would take a long time to do.
>> Well then, I should better contribute the themes I already have to
>> standard-themes.
>
> I am confused, what themes do you mean?
I already have the wombat and adwaita themes (partially) rewritten using
modus.
--
- E.G via Gnus and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Wed, 05 Nov 2025 08:17:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79696 <at> debbugs.gnu.org (full text, mbox):
On Sat, 25 Oct 2025 at 15:52, Stéphane Marks <shipmints <at> gmail.com> wrote:
> Whenever I see people discuss some custom theme or other in the wild, I encourage
> them to do the same thing: theme modus instead of purely standalone. If I found a
> theme in the wild that was modus based, I'd be way more likely to try it than not.
By the way, I wish there was a simple way to "theme" a theme. Modus has
broad customization options but not a way to override individual faces
AFAICT?
In other words, I think there should exist a `define-derived-theme'
function. I bet I wasn't the only user who had to cook up their own
version of such a thing :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79696; Package
emacs.
(Wed, 05 Nov 2025 11:29:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 79696 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Nov 5, 2025 at 3:16 AM Augusto Stoffel <arstoffel <at> gmail.com> wrote:
> On Sat, 25 Oct 2025 at 15:52, Stéphane Marks <shipmints <at> gmail.com> wrote:
>
> > Whenever I see people discuss some custom theme or other in the wild, I
> encourage
> > them to do the same thing: theme modus instead of purely standalone. If
> I found a
> > theme in the wild that was modus based, I'd be way more likely to try it
> than not.
>
> By the way, I wish there was a simple way to "theme" a theme. Modus has
> broad customization options but not a way to override individual faces
> AFAICT?
>
> In other words, I think there should exist a `define-derived-theme'
> function. I bet I wasn't the only user who had to cook up their own
> version of such a thing :-).
>
You can use modus-themes-theme to derive a new theme and override faces and
add new ones.
https://protesilaos.com/emacs/modus-themes#h:412e3017-81fe-4a95-97a6-225de1867757:~:text=The%20standard%2Dthemes%2Dcustom,of%20the%20active%20theme
.
Prot's refined ef-themes now derived from modus-themes uses this feature.
[Message part 2 (text/html, inline)]
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.