Eli Zaretskii writes: >> From: "J.D. Smith" >> Cc: philipk@posteo.net, 78995@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Sun, 03 Aug 2025 14:16:05 -0400 >> >> > Can we have a comment here explaining the reason for the use of >> > autoload-macro? >> > And maybe here as well? >> > And here. x 4 >> >> I'm not sure what kind of comment you mean. > > To explain why do we use this declaration there. > >> Are you thinking of something simple, like "request macro-expansion >> during autoload generation"? > > 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. Meta-comments: ============== Though outside of the scope of this patch, a few mildly bothersome attributes remain, which I leave here for posterity. 1. It's somewhat arbitrary which macros request expansion Eventually, I think for all builtin macros, the question should be asked: "Will calls to this macro likely be marked ;;;###autoload"? If the answer is yes, the macro should declare `autoload-macro=expand', so that these calls get recursively expanded down to their most basic forms — `defalias', `put', and so on. 2. Some autoloaded macro expansions are not "autoload-hygienic". Some macros currently /rely/ on skipping directly to `(autoload name ...)' generation via the hard-coded "short-cut" list (see `loaddefs--defining-macros'). I.e. they do not expect to be expanded, and are therefore not autoload-hygenic in their expansion (e.g. neglecting to use `:autoload-end' to elide unwanted forms, for example). This is confusing and prone to bugs (e.g. the bug discovered in this thread related to the MODES arg). 3. Some macros' autoload treatment depend on whether they are defined at autoload-generation time. Such macros are both on the short-cut list /and/ request expansion. So they are expanded, but only if they are defined at the time autoload generation occurs. Most are, but some, e.g. cl-macs, are not. So they go through the "short-cut" instead. IMO, these macros should either have their expansion cleaned up for autoload hygiene (if necessary) and be pre-loaded during autoload generation, or they should just not request expansion at all.