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: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78995 <at> debbugs.gnu.org
Subject: bug#78995: [PATCH] ;;;autoload-expand for special macros
Date: Sat, 12 Jul 2025 22:25:05 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> The only list that I've found a need to extend is the (1) above, so
> I wouldn't worry too much about the other two.
>
> [ Declaring specific macros as "to be expanded for autoload" (as opposed
>   to marking specific autoloaded macro calls), would still be overall
>   better, since it would solve the question of "what about macros that
>   expand to something that also needs expanding".  ]

That's a good point.  It would relieve us of the binary choice of
"expand just this form" vs. "expand any and all macros this form expands
to", which isn't ideal.  But I wonder what the best approach is?  A
file-local variable, which extends the (1) list only for that file?

We _could_ do both: an ;;;###autoload-expand magic comment for "expand
this one", and a optional file-local variable, something like
`autoload-extra-expand-macros', naming additional macros to expand at
any depth[1] (if needed).  We could even allow elements of the list to
look like (MACRO . FILE) for an additional FILE to define MACRO load
(for the evil people), defaulting to `(file)' (meaning: this file).

That's some duplication of purpose, and you don't technically need the
magic form, but formatting file-local variables is a pain if you don't
need them.

[1] Would we possibly have to guard against recursive macro definitions?
    An advantage of "just this next form" expansion is you don't have to
    worry about that.

Previous Next

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