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

Previous Next

Full log

Message #29 received at 78995 <at> debbugs.gnu.org (full text, mbox):

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

>> I don't think it's good enough.  Many of the use-cases I've bumped into
>> use macros defined in another file (or even another package).
> Doesn't a file usually need to require such files/packages in order to
> make use of their macros?

Duh!  You're right.

> Or perhaps the issue arises in cases like multi-file packages where
> `declare-function' is used because you know the load order.  I.e. if:

No, no, these are "evil" and they get what they deserve.

>> I think we should aim to provide a mechanism that lets us reduce the
>> size of the hardcoded list (ideally to nothing).
>
> There are actually _multiple_ hard-coded lists in
> `loaddefs-generate--make-autoload':
>
> 1. Macros to expand (by name) and recurse on the expansion.
> 2. "Function-like operators", which get an `(autoload ...)' form
>   created for them.
> 3. Macros which are known to produce interactive function definitions
>    (to set the INTERACTIVE arg for the generated autoload).

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".  ]


        Stefan

Previous Next

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