|
From: | Jack Hill |
Subject: | [bug#42736] [PATCH] gnu: emacs-doom-themes: Update to 2.1.6-5. |
Date: | Fri, 7 Aug 2020 22:09:39 -0400 (EDT) |
User-agent: | Alpine 2.21 (DEB 202 2017-01-01) |
On Thu, 6 Aug 2020, Brett Gilio wrote:Hey Jack, Thanks for taking time to revise this package. When I originally wrote it I made notice to the fact that some elisp bytecompilations were failing or not behaving appropriately. Since then I am pretty sure hlissner has disabled the bytecompilation completely? Could you review this for me, and if true please revise the appropriate arguments. If you aren't sure what I am talking about, please let me know.
Brett,I think the way forward is to follow upstream's choices and not enable or disable byte compilation in Guix.
After upstream introduced commit 9cd6872 [0], our trick to selectively leave batch compilation enabled for some files didn't work because they already had `-*- no-byte-compile: t; -*-` at the top of the file. In my testing, I added a phase to substitute this away. Indeed, this allowed our trick to work again. However, the material, snazzy, and tomorrow-day themes now have problems with byte compilation.
Therefore, I removed the disable-breaking-compilation phase entirely. With it removed, doom-themes-autoloads.el, doom-themes-base.el, doom-themes.el, doom-themes-ext-org.el, and doom-themes-ext-visual-bell.el do get byte compiled. From this evidence I concluded that upstream is aware of this issue and is only disabling byte compilation where necessary.
I'll send a version 2 of the patch with the phase removed shortly. [0] https://github.com/hlissner/emacs-doom-themes/commit/9cd6872b1af88165834230abd45743036861f925 Best, Jack
[Prev in Thread] | Current Thread | [Next in Thread] |