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

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

bug#54802: OClosure: Make `interactive-form` a generic function


From: Po Lu
Subject: bug#54802: OClosure: Make `interactive-form` a generic function
Date: Fri, 15 Apr 2022 09:37:43 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hmm... odd.  I know the problem doesn't show up if you have
> `gnus-score.el` loaded beforehand, but otherwise I wonder how you dodged
> that "bullet" (not that it matters, it's fixed now anyway; just curious).

Probably because every autoload that could cause problems was already
loaded.

> Talking about curious, I wonder what you use that loop for.

It was originally supposed to demonstrate the feasibility of a
"context-sensitive" menu in Emacs, i.e. one that displays commands
pertinent to the region when it is active, etc.

But in the end I made a completing-read wrapper around it, which does
make it easier to find some odd commands I can't remember.

>> OClosures are records, right?  There's no other record type that can be
>> a function with an interactive form, so we could just use `recordp'
>> instead of calling into Lisp for that.
>
> They're somewhat like records but they're not `recordp`, they're `functionp`.

[...]

> Part of the 2x slowdown is due to generic dispatch but part is due to
> the fact the code is in ELisp rather than in C, so even a "perfectly
> fast" generic dispatch wouldn't get us back the factor 2x.
> And speeding up generic dispatch is not super easy.

Hmm, so what about having a special "OClosure" pseudovector type on the
C level which would otherwise behave like byte-code functions, but
behave specially in `interactive-form'?

Thanks.




reply via email to

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