Re: Byte-compilation of custom themes

[Basil L. Contovounesios]

0001-Clarify-byte-compilation-of-Custom-Themes-in-Elisp-m.patch
Description: Text Data

Stefan Monnier <address@hidden> 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