Use-package: New problem with diminish

Created on 7 Dec 2017 · 8Comments · Source: jwiegley/use-package

When doing a change in my init.el, Emacs sometimes decides to freeze for a few seconds and display that in the *Messages* buffer:

Saving file /home/cassou/.emacs.d/init.el...
Wrote /home/cassou/.emacs.d/init.el
ad-handle-definition: ‘enable-theme’ got redefined
Configuring package frame...done (0.468s)
ad-handle-definition: ‘pop-to-mark-command’ got redefined
[...]
Wrote /home/cassou/.emacs.d/init.elc
Wrote /home/cassou/.emacs.d/init.{el,elc}

This has been like that for quite some time. But with a recent use-package version from git, after Emacs has frozen for a few seconds, I now get all minor modes in the modeline. I usually have them disappear with :diminish.

Standard mode-line:

After saving my init.el:

bug

Source

DamienCassou

Most helpful comment

@DamienCassou So, this will be another chapter for the manual, but:

Byte-compiling so that it produces meaningful errors and warnings is a tricky thing. If you byte-compile and see thousands of warnings about things not being defined, you won't see the ones that are really not defined after the package has loaded.

What use-package does to counter this is that, only when byte-compiling, it injects some eval-when-compile forms that attempt to load your package, no matter what your keyword settings are. This is done to bring all of that package's definitions into scope, for the sake of expanding later macro definitions in the init file, and so we can really see which references are undefined.

Thus, byte-compiling init.el within a running Emacs will cause everything to be loaded again, but this time without doing it the way you've requested. This means that use-package-based init files should only ever be byte-compiled offline, using emacs --batch -f batch-byte-compile-file. There's an example of how I do this here:

https://github.com/jwiegley/dot-emacs/blob/master/Makefile#L65

jwiegley on 8 Dec 2017

👍3

All 8 comments

Which commit are you on? This seems like it's likely an issue in use-package but as a workaround I'd recommend trying delight instead, it tends to be more stable than diminish in my experience. Also, I wonder if this could be related to abd3698bc0b5cebe8abd697e10edce8d34e1af80.

nickmccurdy on 7 Dec 2017

@DamienCassou I take it you're using something like auto-compile to recompile your init.el file?

jwiegley on 7 Dec 2017

I am using auto-compile, indeed:

(use-package auto-compile
  :demand t
  :init
  (progn
    (setq auto-compile-display-buffer nil)
    (setq auto-compile-mode-line-counter t)
    (setq auto-compile-source-recreate-deletes-dest t)
    (setq auto-compile-toggle-deletes-nonlib-dest t)
    (setq auto-compile-update-autoloads t))
  :hook (auto-compile-inhibit-compile . auto-compile-inhibit-compile-detached-git-head)
  :config
  (progn
    (auto-compile-on-load-mode)
    (auto-compile-on-save-mode)))

I'm following recommendation from borg IIRC.

DamienCassou on 8 Dec 2017

I don't know what the interaction between these two might be, especially since you're byte-compiling your init file itself. Do you think this is something to be addressed in use-package?

jwiegley on 8 Dec 2017

I've just seen that auto-compile explicitly recommends not byte-compiling the init.el file. I will follow this advice from now on. I'm not sure what use-package could do about it but I was surprised that each compilation of my init file would execute my use-package recipes (as opposed to just expanding and compiling the expansion).

DamienCassou on 8 Dec 2017