background mode/color, foreground color incorrect after modus-themes-toggle

[shipmints]

This is Emacs 29.4. I haven't yet tried it on an Emacs 30 build and latest ELPA modus-themes-20241028.849.

Starting with vivendi from a clean restart.

M-x modus-themes-toggle to operandi.

Now M-x make-frame with operandi in effect. The new frame is screwed up.

I've added this stanza to solve the issue.

    ;; these parameters are not correctly copied by make-frame.
    (add-to-list 'frame-inherited-parameters 'background-mode)
    (add-to-list 'frame-inherited-parameters 'background-color)
    (add-to-list 'frame-inherited-parameters 'foreground-color)

Now after the toggle, the new frame looks fine:

FYI, clone-frame works fine but not make-frame.

[protesilaos]

From: shipmints @.***> Date: Wed, 6 Nov 2024 09:05:42 -0800

This is Emacs 29.4. I haven't yet tried it on an Emacs 30 build.

I cannot reproduce this in Emacs 31.

[... 12 lines elided]

I've added this stanza to solve the issue.

    ;; these parameters are not correctly copied by make-frame.
    (add-to-list 'frame-inherited-parameters 'background-mode)
    (add-to-list 'frame-inherited-parameters 'background-color)
    (add-to-list 'frame-inherited-parameters 'foreground-color)

[... 5 lines elided]

I checked all the 'deftheme' we have and their ':background-mode' looks correct in all cases. Do you think there is something we can do here?

-- Protesilaos Stavrou https://protesilaos.com

[shipmints]

Did you try this on a Mac? If you can explain how theme-oriented frame variables are propagated when a new frame is created under normal circumstances, I can try to track down what's going on. If this turns out to be Mac (NS) specific, that might be a hint.

[protesilaos]

From: shipmints @.***> Date: Thu, 7 Nov 2024 06:25:47 -0800

Did you try this on a Mac?

No, I only have Linux here.

Try to reproduce this with other themes. I suspect it is not a Modus issue.

-- Protesilaos Stavrou https://protesilaos.com

[shipmints]

I've tracked it down to the below snippet, but it's not clear why this interferes with theme switching. Perhaps you have sufficient depth in this area to illuminate what Emacs is doing.

The below is executed before modus-themes are enabled (I have an option to run themeless, so sensible defaults make sense to set). If I comment out background and foreground (or set them explicitly to 'unspecified), theme switching works fine on new frames. Why would setting the default face interfere with themes only on new frames but not the current frame where the theme is enabled? Don't themes override the default face? If Emacs has a default face takes precedence over a theme default face, it should also appear to interfere on the first frame. There's nothing explicit that I can see to control this behavior.

(set-face-attribute 'default nil
                    :family "Inconsolata"
                    :height 200
                    :weight 'normal
                    :width 'normal
                    :slant 'normal
                    :background "#101010"
                    :foreground "white" ; use theme foreground
                    :inherit nil :extend nil :stipple nil :inverse-video nil :box nil :strike-through nil :overline nil :underline nil)

If this turns out to be interfering with theming for other people, it might make sense to add something to the documentation to suggest to avoid setting background and foreground if they want themes to take precedence on all frames. In my case, at least I can now set these conditionally on themes being enabled. But why...is this Mac/NS specific behavior? Thanks for your assistance in solving this mystery.

[shipmints]

Related Emacs theme behavior differences GUI to tty of which to be aware since you're the de facto Emacs theme master: https://github.com/alphapapa/prism.el/issues/32#issuecomment-2466238247

[protesilaos]

From: shipmints @.***> Date: Sat, 9 Nov 2024 06:27:31 -0800

Related Emacs theme-related behavior of which to be aware since you're the de facto Emacs theme master: https://github.com/alphapapa/prism.el/issues/32#issuecomment-2466238247

Perhaps this is related to the bug I reported for 'custom-set-faces': https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-10/msg01794.html

-- Protesilaos Stavrou https://protesilaos.com

[shipmints]

Seems like Eli thinks the "feature" is intended. Perhaps a user option, then, to control the behavior is a step toward normalizing it. That Emacs on tty resets the default face bg and fg to undefined is a bit unexpected as Adam has to guard against in prism and the documentation suggests that can not happen.

[protesilaos]

From: shipmints @.***> Date: Sun, 10 Nov 2024 06:21:16 -0800

Seems like Eli thinks the "feature" is intended. Perhaps a user option, then, to control the behavior is a step toward normalizing it. That Emacs on tty resets the default face bg and fg to undefined is a bit unexpected as Adam has to guard against in prism and the documentation suggests that can not happen.

I am not sure what the best solution is. I think long-term the best outcome is for bugs in Emacs to be solved there instead of package maintainer trying to work around them. Especially for those cases where the bug is not reproducible with all Emacs builds.

-- Protesilaos Stavrou https://protesilaos.com