Open bram85 opened 3 months ago
According to the face-attribute
docstring:
To ensure that the return value is always specified and absolute, use a
value of ‘default’ for INHERIT; this will resolve any unspecified or
relative values by merging with the ‘default’ face (which is always
completely specified).
If your default
face has unspecified attributes, that might indicate a bug elsewhere, unless I'm misunderstanding something.
According to the Elisp manual, as I quoted, the default face is supposed to be always completely specified. Yet after running emacs -q -nw
, (face-attribute 'default :background nil 'default)
returns "unspecified-bg"
. That would seem like a bug, in the documentation if nothing else.
I'd suggest that someone search the Emacs bug tracker for reports related to this; I'd be surprised if it's never come up before.
I don't know yet what the best solution is, but a potential workaround is to wrap the body of prism-after-theme
in ignore-errors
, like:
(defun prism-after-theme (&rest args)
"For `load-theme' advice.
ARGS may be what `load-theme' and `disable-theme' expect. Unless
NO-ENABLE (optional third argument, like `load-theme') is
non-nil, call `prism-set-colors' to update `prism' faces."
(ignore-errors
(unless (cl-third args)
(prism-set-colors))))
That prevents the error from disable-theme
, and then when the next theme is loaded, it works as expected.
Having the same issue with prism on tty when changing themes via modus-themes-toggle which first disables all themes and then enables the specified theme. Digging into it, Emacs behavior GUI to tty is different when disabling themes and it resets bg and fg colors to unspecified. If prism advises after disable-theme, prism color resetting will always fail on a tty if it does not guard against unspecified. Below is the same on 29.4 and current master.
(defun disable-theme (theme)
...
(set-frame-parameter frame 'background-color
(custom--frame-color-default
frame :background "background" "Background"
"unspecified-bg" "white")) ; <--- tty-default is unspecified
...
(defun custom--frame-color-default (frame attribute resource-attr resource-class
tty-default x-default)
...
Some archaeology:
https://lists.gnu.org/archive/html/emacs-diffs/2022-05/msg00863.html
The
prism-after-theme
advice is broken when it is called afterdisable-theme
on a terminal. The advice callsprism-set-colors
which in turn callsprism-blend
.disable-theme
calls:On a terminal, this will set the frame background color to
unspecified-bg
.prism-set-colors
would retrieve the background color for theparens-fn
parameter:This results in the following backtrace:
I created a workaround to add an advice to
prism-blend
and intercept any unspecified colors:Personally I only encounter this issue when calling
modus-themes-toggle
, which is roughly a sequence ofdisable-theme
andload-theme
. Therefore the workaround is sufficient for me, as I wouldn't observe the blending result with the white dummy color. But it wouldn't generalize well for those who rundisable-theme
in isolation.