bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45333: complex command history should not save optional nil paramete


From: Stefan Monnier
Subject: bug#45333: complex command history should not save optional nil parameters
Date: Wed, 06 Jul 2022 14:41:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>> (Which reminds me -- I've always found it odd that that function lives
>> in help.el, and is in Emacs Lisp instead of C.  It is, after all, used
>> by eldoc etc, and it'd probably be nice if it were more efficient.)
> So I started taking a stab at this to see whether there's any gains to
> be had, and I've now basically rewritten it in C.

IIUC you're talking about `help-function-arglist`?

> And, yes, I think it makes sense, because we can avoid at least some
> garbage generating functions without contorting ourselves too much.

I can't think of any reason we'd ever want to use that function anywhere
near performance critical code, so I'd rather keep it in ELisp if
possible.  `help.el` may not be the best choice for it, admittely.
Over the course of my hacking on OClosures, I had moved that code (and
the accompanying fundoc extraction/addition) to `subr.el` where I think
it might make more sense (together with a bit of renaming to take it out
of the `help-` namespace).

> One thing, though -- I'm not sure how to do the oclosure stuff from C,
> so I've added Stefan to the CCs.  It's this bit:
>
>   ;; Advice wrappers have "catch all" args, so fetch the actual underlying
>   ;; function to find the real arguments.
>   (setq def (advice--cd*r def))

OClosure or not doesn't make much of a difference here, I think (the
previous version of the code would also be quite hideous in C).
Why not just call `advice--cd*r`?


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]