pr fix autoload generation recursion error

[matsl]

What

Do not load and generate autoloads from hload-path while in batch
processing (such as byte compiling).

• Do not load and generate autoloads from hload-path in batch
• Remove compile dependency on loading autoloads

Why

When generating autoloads in Emacs 31 we get this error below. It does
not occur with older versions.

Eager macro-expansion failure

❯ make clean autoloads
  GEN      kotl/kotl-autoloads.el
  INFO     Scraping 66 files for loaddefs...
hibtypes:0: Warning: Not registering prefix "hy".  Affects: ("hyrolo-stuck-msg" "hyp-manual" "hyp-address" "hyp-source" "hywiki-word" "hywiki-existing-word")
loaddefs-gen: loading file hsys-youtube (for defact)
Loading /home/matsl/src/hyperbole/hsys-youtube.el (source)...
Warning (emacs): loaddefs-gen: load error
	(error "Eager macro-expansion failure: (error \"Eager macro-expansion failure: (error \\\"Recursive load\\\" \\\"/home/matsl/share/emacs/31.0.50/lisp/jka-compr.el.gz\\\" \\\"/home/matsl/share/emacs/31.0.50/lisp/jka-compr.el.gz\\\" \\\"/home/matsl/share/emacs/31.0.50/lisp/jka-compr.el.gz\\\" \\\"/home/matsl/share/emacs/31.0.50/lisp/jka-compr.el.gz\\\" \\\"/home/matsl/share/emacs/31.0.50/lisp/jka-compr.el.gz\\\" \\\"/home/matsl/share/emacs/31.0.50/lisp/emacs-lisp/pcase.el.gz\\\" \\\"/home/matsl/src/hyperbole/set.el\\\" \\\"/home/matsl/src/hyperbole/hact.el\\\" \\\"/home/matsl/src/hyperbole/hsys-youtube.el\\\" \\\"/home/matsl/src/hyperbole/hload-path.el\\\")\")")
  INFO     Scraping 66 files for loaddefs...done
  GEN      hyperbole-autoloads.el
  INFO     Scraping 13 files for loaddefs...
  INFO     Scraping 13 files for loaddefs...done
  GEN      kotl-autoloads.el
Initializing Hyperbole...
Initializing Hyperbole...done
  INFO     Scraping 14 files for loaddefs...
  INFO     Scraping 14 files for loaddefs...done

The recursive load seems to origin from hload-path.el having a call to
check if autoloads are generated and if not generate and load them.

This PR tries to solve this by limiting the generation and loading of
autoloads to an interactive Emacs.

Further, the byte compile errors that occurs due to not loading
autoloads are resolved by adding declare-function and defvar. Each
el-file is by that possible to compile without having to load the
autoloads.

Note

I though this was a good experiment for solving the loaddefs-gen issue
by decoupling byte compilation from autoloads generation.

It also brought my attention to that we generate autoloads from
hload-path which feels a bit odd. I mean for normal use the autoloads
are generated by the package manager or, when running from source, by our
make target. Anyway this PR does not change that. An interactive Emacs
behaves the same.

[rswgnu]

The hload-path autoload generation is from long ago as is that whole setup when Emacs could not find its own executable directory. Are you saying that the PR has all the defs needed to work if there are no autoloads?  If so, we should be able to go with this.

[matsl]

The hload-path autoload generation is from long ago as is that whole setup when Emacs could not find its own executable directory.Are you saying that the PR has all the defs needed to work if there are no autoloads? If so, we should be able to go with this.

Yes, I think that is the case. Our CI build targets does generate autoloads before byte compiling so the CI build is not a perfect confirmation of that. It is just an indirect one since the hload-path check for the autoloads requires an interactive Emacs.

I have tested locally by running "make clean new-bin" which builds the elcs without building the autoloads. I have also tested to start en Emacs without the autoloads and then they are generated and loaded. The later I guess is what always happens when you run from source without using a package manager.

[rswgnu]

Generally fine, fix 2 comments and then can approve.

[rswgnu]

The issue is if the call references any symbols defined in the file below it or loaded after the call is made.  So you basically have to test all the run paths of any function calls you move.-- BobOn May 14, 2026, at 9:59 AM, Mats Lidell ***@***.***> wrote: @matsl commented on this pull request. In hycontrol.el:

@@ -91,7 +91,7 @@

;; perpendicular to that edge by 50% while keeping the original edge OK. Lets fix that first then since the location of these definitions when placed down in the file caused many compile warnings because of access to these symbols from within the file. Those could be resolved by forward declarations in the top of the file but I find that to be a code smell if it can be resolved within a file by fixing the order. Since these are autoloaded they did not case any errors when we load the autoloads before byte compiling. So to resolve the warnings I moved the code block up to be before where they are referenced and did not think more about that. What issues can there be due to that rearrangement? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because your review was requested.Message ID: ***@***.***>

[matsl]

I moved out the hycontrol changes. So now we have these warnings that the change to hycontrol was fixing:

hycontrol.el:581:9: Warning: assignment to free variable
hycontrol.el:582:9: Warning: assignment to free variable
hycontrol.el:603:10: Warning: reference to free variable
hycontrol.el:1077:13: Warning: reference to free variable
hycontrol.el:1077:35: Warning: reference to free variable
hycontrol.el:1098:11: Warning: reference to free variable
hycontrol.el:1100:11: Warning: reference to free variable

[matsl]

See PT #954 for the hycontrol changes as requested in a separate PR.