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:09:59 -0500
> 
> > I'm saying that your proposal of fixing this will cause these
> > functions to do some parts of their jobs before they realize that they
> > can barf, and this will now happen even when they run not from a
> > keyboard macro, and even if the keyboard macro doesn't actually
> > provide any input.  This is definitely not TRT.  It affects use cases
> > completely unrelated to the ones you wanted to fix, and affects them
> > in adverse ways.
> 
> I think the effects on other use cases are only positive.  If, for
> example, read-char would fail due to reasons other than
> inhibit-interaction, it will now fail for those reasons.  Which is good,
> because it reduces the need for all code everywhere to think about the
> possibility that inhibit-interaction is non-nil.

Most calls don't signal errors, so the part that is important is when
they don't.

> > Please find a way of fixing the case of a keyboard macro that provides
> > input without adversely affecting the other cases where these
> > functions are called with inhibit-interaction=t.
> 
> How about if those original barf_if_interaction_inhibited calls only
> signal if executing-kbd-macro is nil?

We could perhaps do that, but see my other message: I think it is
fundamentally wrong to allow keyboard macros be exempt from this
feature.

> >> - Users write functions using keyboard macros and put them in hooks,
> >>   which happen to get invoked by packages which use inhibit-interaction.
> >>   Those functions don't actually require interaction, but because they
> >>   break, ultimately no code can use inhibit-interaction.
> >> 
> >> - I run tests in a batch Emacs, frequently using keyboard macros to
> >>   provide input.  Sometimes a bug causes code to run which calls
> >>   read-char outside of a keyboard macro.  I would like such read-char
> >>   calls to error (instead of hanging, which is what they do by default
> >>   in batch mode).  If I bind inhibit-interaction=t, then read-char will
> >>   exit with an error, but my keyboard macros will also immediately
> >>   error.
> >
> > In both cases, using a function would solve the problem.  So I'm not
> > convinced we need to support those marginal cases, unless you can come
> > up with a solution that will be both simple and will not affect
> > unrelated use cases.
> 
> - Are you suggesting that novice users should have to rewrite all their
>   keyboard macros in Lisp?  That sounds impractical.

I don't see anything impractical here.

> - How can I provide keyboard input to the interactive spec of a command
>   I am testing, other than by using keyboard macros?  I'd be pleased to
>   have an alternative solution.

Why do you need to do that when inhibit-interaction is non-nil in the
first place?  Code that needs interaction shouldn't be run or tested
in those conditions.