GNU bug report logs - #78995
[PATCH] ;;;autoload-expand for special macros

Previous Next

Full log

View this message in rfc822 format

From: "J.D. Smith" <jdtsmith <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: philipk <at> posteo.net, 78995 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#78995: [PATCH] ;;;autoload-expand for special macros
Date: Sun, 03 Aug 2025 18:53:34 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "J.D. Smith" <jdtsmith <at> gmail.com>
>> Cc: philipk <at> posteo.net,  78995 <at> debbugs.gnu.org,  monnier <at> 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.

[autoload-expand_8.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.