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

Previous Next

Full log

Message #23 received at 54802 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 54802 <at> debbugs.gnu.org
Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function
Date: Fri, 15 Apr 2022 08:46:55 +0800

Stefan Monnier <monnier <at> 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.

Previous Next

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