|
From: | Basil L. Contovounesios |
Subject: | Re: Byte-compilation of custom themes |
Date: | Thu, 10 May 2018 03:49:35 +0100 |
User-agent: | Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
0001-Improve-loading-of-byte-compiled-custom-themes.patch
Description: Text Data
0002-Disable-no-byte-compile-in-built-in-themes.patch
Description: Text Data
0003-Fix-custom-available-themes-file-expansion.patch
Description: Text Data
0004-lisp-custom.el-Use-lexical-binding.patch
Description: Text Data
0005-lisp-cus-theme.el-Use-lexical-binding.patch
Description: Text Data
0006-Various-custom.el-simplifications.patch
Description: Text Data
0007-Various-cus-theme.el-simplifications.patch
Description: Text Data
0008-Minor-subr-x-tweaks.patch
Description: Text Data
Stefan Monnier <address@hidden> 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
[Prev in Thread] | Current Thread | [Next in Thread] |