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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  67837@debbugs.gnu.org,
>    larsi@gnus.org
> Date: Fri, 15 Dec 2023 14:48:51 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please explain why you are removing the calls to
> > barf_if_interaction_inhibited from many functions.  It looks like they
> > will now do some work instead of barfing right at the beginning.  Why
> > is that TRT?
> 
> Those calls to barf_if_interaction_inhibited meant inhibit-interaction
> was checked before the keyboard macro code had a chance to provide
> input.
> 
> I am moving the check on inhibit-interaction to run after checking
> executing-kbd-macro in the low-level input handling mechanism,
> read_char.

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.

> This allows the keyboard macro is allowed to provide input even if
> inhibit-interaction=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.

> > And I don't think I understand why we should care about a case when
> > inhibit-interaction is non-nil, and Emacs needs to execute a keyboard
> > macro, since executing keyboard macros is basically similar to
> > interactive invocations of commands.  What are the real-life use cases
> > for that?
> 
> Two concrete, real-life use cases:
> 
> - 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.