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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "J.D. Smith" <jdtsmith <at> gmail.com>
Cc: 78995 <at> debbugs.gnu.org
Subject: bug#78995: [PATCH] ;;;autoload-expand for special macros
Date: Sat, 12 Jul 2025 22:47:44 -0400

>> 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?

FWIW, I've come to the opinion that what you propose and what I want
match different use-cases.  The one I care about is when a package
provides a (typically autoloaded) macro like `define-minor-mode`, for
use by other packages.  But what you propose matches the use-case where
a package defines its own macro for it own internal use, usually with
no intention to autoload it.

> A file-local variable, which extends the (1) list only for that file?

I'm thinking we should replace the hardcoded list with a symbol
property.  When defining macros like `define-minor-mode` we'd set this
`autoload-macroexpand` property to a non-nil value, and `autoload.el`
would simply check the property instead of looking inside the hardcoded
list with `memq`.

This would work only for predefined or autoloaded macros (where the
`autoload-macroexpand` setting would be also pre-defined/loaded), so
it wouldn't work conveniently for a locally-defined and locally-used
macro, since you'd then need to somehow set the property and define or
autoload the macro before `autoload.el` gets to the macro calls.

So I think your approach might be a good solution for the case of local
macros.  I don't know how often we need such a thing, tho.  I can't
remember bumping into it, but it might be because I'd intuitively avoid
it, knowing we don't have support for it.

I assume there's a concrete use-case which motivated your patch.
Do you mind sharing it?


        Stefan

Previous Next

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