Stefan Monnier writes: >> diff --git a/doc/lispref/customize.texi b/doc/lispref/customize.texi >> index 6c7ca260ab..7fea507fd0 100644 >> --- a/doc/lispref/customize.texi >> +++ b/doc/lispref/customize.texi >> @@ -1432,7 +1432,9 @@ Custom Themes >> would be evaluated when loading the theme, but that is bad form. >> To protect against loading themes containing malicious code, Emacs >> displays the source file and asks for confirmation from the user >> -before loading any non-built-in theme for the first time. >> +before loading any non-built-in theme for the first time. As >> +such, themes are not ordinarily byte-compiled, and source files >> +always take precedence when Emacs is looking for a theme to load. >> >> The following functions are useful for programmatically enabling and >> disabling themes: > > Sounds good to me. I attach a patch with this amendment. If it is up to scratch, would someone please push it? >> Why are built-in themes not exempt to this safety net, though? > > They're not? There is code which tries to exempt them, so if they're > not, it's a bug in that code. Sorry, I should have been clearer. As documented, load-theme indeed exempts built-in themes from the custom-theme-load-confirm check. What I meant to ask is why built-in themes are not byte-compiled in addition to being considered safe. Are there any arguments against doing this, other than any performance gain being negligible? >> Finally, would you care to post your helpful explanation as an answer to >> my Stack Exchange question, or would you rather I paraphrased this >> thread? > > Feel free to post my answer there, Done: https://emacs.stackexchange.com/a/38510/15748. Thanks, -- Basil