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

Previous Next

Package: emacs;

Reported by: JD Smith <jdtsmith <at> gmail.com>

Date: Fri, 11 Jul 2025 19:29:02 UTC

Severity: normal

Tags: patch

Fixed in version 31

Done: "J.D. Smith" <jdtsmith <at> gmail.com>

Full log


View this message in rfc822 format

From: JD Smith <jdtsmith <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 78995 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#78995: [PATCH] ;;;autoload-expand for special macros
Date: Sat, 12 Jul 2025 10:59:45 -0400
[Message part 1 (text/plain, inline)]
Thanks, improved doc-strings in the attached.  If this is looking good I can also update the `Autoload' section of the elisp manual, near "If you write a function definition with an unusual macro...".  I also noticed that `:autoload-end' is not mentioned there, and probably should be (this keyword marker halts further processing of forms in the macro expansion).

One question on nesting of macros: I'm wondering whether an ;;;###autoload-expand should result in using `EXPANSION=force' in all recursive calls to `loaddefs-generate--make-autoload'.  I.e. should all macros be _recursively_ expanded with `force'?  This would allow nesting, e.g. a macro wrapping a macro which itself wraps `define-minor-mode'.  But it would also expand all other macros encountered in the expansion, which could be problematic.  My instinct is that one level of such forced macro expansion is all that can be safely supported.

[autoload-expand.patch (application/octet-stream, attachment)]

This bug report was last modified 27 days ago.

Previous Next


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