Eli Zaretskii writes: >> From: "J.D. Smith" >> Cc: philipk@posteo.net, 78995@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Sun, 03 Aug 2025 18:53:34 -0400 >> >> > No, I mean _why_ we want to request that in those places and not the >> > others. >> >> The short but unsatisfying answer is to preserve the hard-coded list of >> macros to expand, which this functionality replaces and extends. The >> former explanation in `loaddefs-generate--make-autoload' was quite >> terse: >> >> ;; For complex cases, try again on the macro-expansion. >> >> I've tried to inject a short explanation everywhere this declaration is >> used. I left the `byte-run--set-autoload-macro' alone, since that's >> just a generic property setter, and values other than `expand' may be >> used in the future. Latest patch below. > > This is much better (thanks!), but I think we need to improve it some > more by saying in the manual that this declaration is an alternative > to hard-coding macros in loaddefs--defining-macros in loaddefs-gen.el. OK, I have implemented these doc suggestions and a few other minor improvements in the attached. I've also tried to make a somewhat unclear situation w.r.t. the hard-coded macro lists more clear in the comments. `loaddefs--defining-macros' is the "shortcut" list for turning a function-defining macro directly into an (autoload ..) form, whereas (autoload-macro expand) replaced a /different/ list of macros: those to be expanded. So there where 2 main hard-coded lists, and now there is 1. The lists are closely related, because usually a macro expands into one or more of the shortcut forms. I conjecture (but have not verified), that ALL hard-coded lists of macros can eventually be removed, save some very basic primitives like defalias (and defmacro?). Whether that's desirable is less clear.