Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> 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?
>
> I can't think of any technical reason, indeed (except that we'd then
> have to special case this in the code so as to load the .elc file
> instead of the .el file).

I went ahead and modified load-theme to support loading byte-compiled
themes considered safe, but then I couldn't resist tweaking some of the
surrounding (in that it all lives under the lisp/ directory) code, so I
attach 8 patches.

The first makes load-theme call load instead of
insert-file-contents+eval-buffer in the non-interactive case of the
theme being considered safe.  This allows either .elc or .el themes to
be loaded with the same semantics as usual Elisp loading.

The second disables the file-local variable no-byte-compile in all the
built-in themes.  Would we want to go one step further and include theme
byte-compilation as part of the build?  Or does that entail too much
effort for little to no gain?

The third simplifies the function custom-available-themes and also fixes
a theoretical issue with its arbitrary expansion of wildcards in custom
theme filenames.

The fourth and fifth enable lexical-binding in custom.el and
cus-theme.el, respectively.

The last three try to make various logic simplifications in custom.el,
cus-theme.el, and subr-x.el, respectively.

I hope this isn't dumping too much in one go.  Please let me know how I
can improve these patches, should any of their suggestions be welcome.

Thanks,

-- 
Basil