[bug#42736] [PATCH] gnu: emacs-doom-themes: Update to 2.1.6-5.

[Brett Gilio <brettg@gnu.org>]

Jack Hill <jackhill@jackhill.us> writes:

>>> 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

Jack,

Thank you for investigating this issue. I agree with your solution, and
I will apply your patch removing the phase.

Brett