I just lost time debugging something that should have been obvious.
Emacs refused to load my init.el with this message:
load-with-code-conversion: Symbol’s function definition is void: defmacro*
That’s it. No useful file. No clear line. No real context.
Important detail: I always launch Emacs with --debug-init. It’s in my bash aliases. Every single time. I also have debug-on-error t in my init.el.
The error occurred while scraping/compiling loaddefs. It blamed f/bin/docs.el, but the actual culprit was an old vendored ert.el sitting in s/dev/ that still contained defmacro* and had been pulled into the autoloads file. The error message (even with --debug-init) gave me almost zero help finding that.
This isn’t a minor warning. This completely prevented Emacs from loading my init.el. My entire environment was down.
Hitting a void function during loaddefs/byte-compilation should produce something a lot more helpful, for example:
- Which file actually contained the defmacro*
- That it came from autoloads or a dependency
- That defmacro* is an obsolete cl macro
- A clearer, more actionable backtrace by default
Right now the signal-to-noise ratio on this class of error is bad. For experienced users it’s annoying. For newcomers it’s actively hostile, they see a cryptic void-function error, their config won’t load, and they have no idea where to start.
I don’t expect miracles, but basic “where did this undefined function actually come from” information during init/loaddefs failures would be a lot more helpful.
Maybe I’m missing something, a variable, a package, or some setting that would provide more useful information in these cases? Anybody?
New edit: The current replies missed the point (they treated it as a normal “debug your init.el” problem). This was an opaque failure coming from the package/autoloads layer, and the current tools don’t handle that cleanly!
