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

[Po Lu]

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

> Do you have actual examples in some existing package?

Just the one I wrote for myself.

> Interesting.  I just tested this in an `all-completions` loop and my
> patch makes it run a factor of 2 slower (it went from ~30ms to ~60ms to
> enumerate the 141 commands that matched).
>
> There are some mitigating circumstances, tho:
> - The first call to this code takes a lot of time (~6s) because
>   it loads a crapload of packages (every package with a registered
>   autoloaded command).

Indeed, that's a problem I know of, but it solves itself after the first
call.

> - It's very brittle since it won't find those commands that have
>   interactive specs like "r\np" or where it's not a string (like
>   `kill-region` and many others, actually there are regularly more, e.g.
>   to make them obey `use-region-p`).

Hmm, I'll try to adapt that code to those commands.

> - That loop signaled an error because of an erroneous autoload in
>   `gnus.el` (it's now fixed in `master`), so your code probably did
>   not do that.

Somehow I never ran into that.

> One reason is that for the case of advice, I'd much rather compute the
> interactive spec lazily (when the command is called) rather than when
> the advice is built.
>
> Another reason is that there is no dedicated "oclosure slot" for an
> interactive-spec.  In theory we could use the byte-code object's slot
> for that, but making it computable (as needed for bug#51695 and for
> advice) would require significant changes to cconv.el and bytecomp.el
> (and to make it not too inconvenient to use in `advice.el` it'd
> additionally require extending the syntax of `interactive`).
>
> We could add a dedicated "oclosure slot" for the interactive-spec, but
> it'd likely be rather ugly, since that would need to be accessed from
> the C in `cmds.c` but would require testing the type of the OClosure
> first and that would have to be written in ELisp since it depends on how
> OClosure types are represented which itself depends on `cl-defstruct`,
> etc...

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.

Alternatively, we could try to speed up generic dispatch, but I don't
know that code and as such am devoid of ideas in that direction.

Thanks.