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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: luangruo <at> yahoo.com, 54802 <at> debbugs.gnu.org
Subject: bug#54802: OClosure: Make `interactive-form` a generic function
Date: Tue, 19 Apr 2022 16:00:58 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: luangruo <at> yahoo.com,  54802 <at> debbugs.gnu.org
> Date: Tue, 19 Apr 2022 08:38:47 -0400
> 
> > I'm sorry, but I think the cleanest fix is too much to pay for a minor
> > feature such as this one.
> 
> I don't see much price to pay here.

See below.

> Am I the only here who finds that defining `interactive-form` as
> an ELisp generic function is, in itself, a good idea (not good enough
> to do it without a good reason, but something I put on the side of
> "advantages" rather than "defects" when assessing my patch)?

Maybe you aren't the only one, but I don't share that opinion.  And in
this particular case, I don't even consider the reason to be anywhere
near "good enough".

> > Can't you find a less intrusive way of fixing these issues, one that
> > doesn't affect all of Emacs for the benefit of one or two packages of
> > minor importance?
> 
> Not sure what you mean by "affect all of Emacs".  It affects
> a well-delimited (and small) part of the code.

It is called outside of the advice functions.

> Are you worried about introducing bugs, about the performance impact,
> or something else?

All of them.  And again, the reason doesn't seem to justify the risks,
not IMO.

Previous Next

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