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: "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: Mon, 04 Aug 2025 11:21:39 -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 18:53:34 -0400
>> 
>> > 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.
>
> This is much better (thanks!), but I think we need to improve it some
> more by saying in the manual that this declaration is an alternative
> to hard-coding macros in loaddefs--defining-macros in loaddefs-gen.el.

OK, I have implemented these doc suggestions and a few other minor
improvements in the attached.  I've also tried to make a somewhat
unclear situation w.r.t. the hard-coded macro lists more clear in the
comments.

`loaddefs--defining-macros' is the "shortcut" list for turning a
function-defining macro directly into an (autoload ..) form, whereas
(autoload-macro expand) replaced a /different/ list of macros: those to
be expanded.  So there where 2 main hard-coded lists, and now there is
1.  The lists are closely related, because usually a macro expands into
one or more of the shortcut forms.

I conjecture (but have not verified), that ALL hard-coded lists of
macros can eventually be removed, save some very basic primitives like
defalias (and defmacro?).  Whether that's desirable is less clear.

[autoload-expand_9.patch (text/x-patch, 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.