emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#73609: closed (29.1; use-package overwrites custom variables in byte


From: GNU bug Tracking System
Subject: bug#73609: closed (29.1; use-package overwrites custom variables in byte-compiled files)
Date: Sat, 09 Nov 2024 09:58:01 +0000

Your message dated Sat, 09 Nov 2024 11:57:21 +0200
with message-id <86ses0n30e.fsf@gnu.org>
and subject line Re: bug#73609: 29.1; use-package overwrites custom variables 
in byte-compiled files
has caused the debbugs.gnu.org bug report #73609,
regarding 29.1; use-package overwrites custom variables in byte-compiled files
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
73609: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73609
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 29.1; use-package overwrites custom variables in byte-compiled files Date: Thu, 03 Oct 2024 06:47:51 +0100
In my config file, I have a use-package statement like this

,----
| (use-package org
| :custom
| (org-log-reschedule nil))
`----

If I byte-compile my config file, run Emacs and run:

,----
| (message "START value is %S" org-log-reschedule)
| (setq org-log-reschedule t)
| (message "BEFORE value is %S" org-log-reschedule)
| (define-advice enable-theme (:before (theme) enable-theme@debug)
|     (message "Loading theme %S" theme)))
| (require 'use-package)
| (message "AFTER value is %S" org-log-reschedule)
`----

I get the messages:
,----
| START value is nil
| BEFORE value is t
| Loading theme `use-package`
| AFTER value is nil
`----

I believe that is because, in my byte-compiled config, `use-package` is no 
longer required since all `use-package` statements are expanded. This means 
that `use-package-core` is also no longer required and in that file, a naked 
(enable-theme 'use-package) statement, which resets all custom random 
variables, is always executed. This is exactly what happens when I eventually 
require `use-package`.

I can fix this by simply always requiring `use-package` in my config so that 
the enable-theme statement in `use-package-core` is executed before I modify 
any variables. Alternatively, this small patch seems to fix the root cause of 
the issue.

--8<---------------cut here---------------start------------->8---
diff --git a/use-package-core.el b/use-package-core.el
index bb523f6..5b1a414 100644
--- a/use-package-core.el
+++ b/use-package-core.el
@@ -38,7 +38,8 @@
   ;; Necessary in order to avoid having those variables saved by custom.el.
   (deftheme use-package))
 
-(enable-theme 'use-package)
+(unless (memq 'use-package custom-known-themes)
+  (enable-theme 'use-package))
 ;; Remove the synthetic use-package theme from the enabled themes, so
 ;; iterating over them to "disable all themes" won't disable it.
 (setq custom-enabled-themes (remq 'use-package custom-enabled-themes))
--8<---------------cut here---------------end--------------->8---

-- Al



--- End Message ---
--- Begin Message --- Subject: Re: bug#73609: 29.1; use-package overwrites custom variables in byte-compiled files Date: Sat, 09 Nov 2024 11:57:21 +0200
> From: abdo.haji.ali@gmail.com
> Date: Wed, 30 Oct 2024 08:49:30 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 73609@debbugs.gnu.org
> 
> 
> > I think this one has to be “won’t fix”, indeed, with a note in the
> > documentation about possible bad interactions between :custom settings and
> > byte-compiled files…
> 
> Just to mention that a fix on the user side would be to always require 
> use-package to force the loading of the theme before other user code is 
> executed. Of course this defeats the purpose of lazy-loading use-package that 
> byte compiling would normally offer.
> 
> An easy “fix” from the use-package side, with virtually zero side effects, 
> would be to move the loading of the theme into a small module that the user 
> can always require without loading all of use-package.

Thanks, I've now updated the use-package manual with the relevant
information (on the emacs-30 branch), and I'm therefore closing this
bug.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]