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

Previous Next

Full log

Message #74 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, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#78995: [PATCH] ;;;autoload-expand for special macros
Date: Sun, 27 Jul 2025 09:11:47 -0400

> I suppose I had imagined multiple flags, à la:
>
>   (autoload (macro-expand something-else))
>
> but maybe that's frowned on.

It's not frowned upon no. You could also have

    (autoload macro-expand something-else)

>> Maybe a "general" solution would be to introduce a `;;;###preload`.
>> Not sure it's worth the trouble, tho.
> Could be considered radical.  I guess the contract would be that all
> `;;;###preload's would happen before all `;;;autoload's?  I can imagine
> people confusing these two (similar to use-package's :init vs. :config).

Yeah, I'd rather not go there (I think it might have made sense to
distinguish the two at the beginning, but now that it's been conflated
for so many years it'd be much harder to introduce the distinction).

>>> +        ;; If the car is entirely unknown, we load the file first to
>>> +        ;; give packages a chance to define their macros.
>>> +        (unless (or (null car) (macrop car) (functionp car) (special-form-p car)
>>
>> I'd test (and (symbolp car) (not (fboundp car)))
>
> For whatever reason, I get lots of nil cars.

Hmm... then there's something I'm missing.
I wonder in which case(s) `car` is nil here.

> So how about:
>
>           (unless (or (not (symbolp car)) (fboundp car) (null car)
>                       ... ;; try to load the file

Fine by me, tho I'd still like to understand why we need to care about `nil`.
We could also add `nil` to the (defclass defcustom deftheme defgroup) list.

> Is
>
> (eq (fboundp x) (or (macrop x) (functionp x) (special-form-p x))) ∀x∈ (symbolp x)?

No.  E.g. `x` could be bound to a keymap, or to a string (old-style
keyboard macro), or potentially to anything else (integer, hash-table,
you name it: that's not useful in the `symbol-function` cell but that
doesn't mean it can't happen).

>> I'd have expected `function-get` here.
> I was honestly vague on the difference.  Seems like `function-get'
> should maybe chase aliases for you...

It does.

>> I think you can just push this to `master` as  separate patch, thank you.
> I've attached a separate patch here (I don't have commit privileges).

Hmm...  According to
https://savannah.gnu.org/project/memberlist.php?group=emacs,
John-David T. Smith does have commit privileges.  I know "Smith" is not
exactly rare, but...

I'll gladly push it, if you prefer, of course.


        Stefan

Previous Next

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