bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: larsi@gnus.org,  67837@debbugs.gnu.org,  monnier@iro.umontreal.ca
> Date: Fri, 15 Dec 2023 15:39:31 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >
> > I'm actually tend to think that this proposal is fundamentally wrong,
> > not just problematic implementation-wise.  Providing input from a
> > keyboard macro is still input, and inhibit-interaction=t means asking
> > for input signals an error.  So your suggestion subverts this feature,
> > and therefore it is simply wrong to install something like that.
> >
> > IOW, signaling an error in these cases is exactly TRT, and we should
> > not let keyboard macros circumvent this mechanism.
> 
> If that's the case, then could we add another variable which does behave
> like I propose with these patches?

Why would we want to do that?

The inhibit-interaction variable was introduced for very special
circumstances, and its purpose is clear: signal an error when any user
interaction is requested.  To introduce some kind of override of that
behavior, in those situations where some Lisp program binds
inhibit-interaction non-nil, would require serious justifications,
since the easiest way of avoiding these problems is either not to bind
inhibit-interaction non-nil in the first place, or provide a signal
handler that will catch the error and DTRT.  Emacs itself never sets
this variable non-nil, it's entirely up to Lisp programs to use it.
And Lisp programs that do bind it actually mean for interactions to
signal an error, so making exceptions from that requires very good
reasons.  I don't think you presented such reasons; the use cases you
described are frankly quite obscure, and can have other solutions.

So I'm against complicating this feature that is currently very simple
and understandable, and also not used widely enough for us to bother
about such contrived circumstances, not enough for non-trivial
internal changes anyway.