Re: Byte-compilation of custom themes

[Basil L. Contovounesios]

Stefan Monnier <address@hidden> writes:

>> Is this "aversion" to byte-compilation of custom themes intentional?
>
> I think it's due to the idea that users might download theme files from
> random places without realizing that it contains arbitrary Lisp code
> (contrary to normal Emacs packages where we consider that users should
> know that it contains arbitrary Lisp code).  So we prompt users to
> confirm that they think the theme file is safe, and users can't be
> expected to assess the safety of a .elc file, so we insist on using the
> .el file, which the user can inspect without nearly as much pain.

Ah, that makes sense.  Do you think it would be worthwhile clarifying
this in the manual?  Is there a clearer way of saying the following?

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:

Why are built-in themes not exempt to this safety net, though?
Diminishing returns?

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?

Thanks,

-- 
Basil