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

[Spencer Baugh <sbaugh@janestreet.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Lars Ingebrigtsen <larsi@gnus.org>
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Fri, 15 Dec 2023 11:50:29 -0500
>> 
>> >From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Fri, 15 Dec 2023 11:39:24 -0500
>> Subject: [PATCH] Make inhibit-interaction work properly with keyboard macros
>> 
>> Previously, inhibit-interaction=t prevented keyboard macros from
>> running, even when those macros did not result in user interaction,
>> since it was checked before the keyboard macro code had a chance to
>> provide input.
>> 
>> Now, if there's a running keyboard macro which can provide input, that
>> keyboard macro is allowed to provide input even if
>> inhibit-interaction=t.  This is achieved by moving the check on
>> inhibit-interaction to run after checking executing-kbd-macro in the
>> low-level input handling mechanism, read_char.
>> 
>> inhibit-interaction also suppresses reading from stdin in batch mode,
>> so we also must add a check on inhibit-interaction to
>> read_minibuf_noninteractive, which again is only called after checking
>> executing-kbd-macro.
>> 
>> * src/keyboard.c (read_char): Add call to
>> barf_if_interaction_inhibited. (bug#67837)
>> * src/lread.c (Fread_char, Fread_event, Fread_char_exclusive): Remove
>> call to barf_if_interaction_inhibited.
>> * src/minibuf.c (Fread_from_minibuffer): Remove call to
>> barf_if_interaction_inhibited.
>> (read_minibuf_noninteractive): Add call to barf_if_interaction_inhibited.
>
> 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.

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

>> +    } else
>
> This is against our style in C sources.

Will fix in next patch.