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

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca
>> Date: Fri, 15 Dec 2023 22:01:01 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > 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.
>
> 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?  That is, it allows input from
keyboard macros, but not from the user?  That is personally what I want
in my packages, because it doesn't break users who use keyboard macros,
and it supports my use case of making read-char error in batch mode.

Or perhaps, another possible value of inhibit-interaction, which behaves
like that?

BTW, I'm curious to hear what Lars thinks, because I expect that
"keyboard macros should not work within inhibit-interaction=t" was not
at all part of the plan.

Although, I guess with my change, a keyboard macro which calls a
function which internally sets inhibit-interaction=t will effectively
ignore the inhibit-interaction setting.  Which is definitely not
correct.

The correct behavior is a bit subtle; also important to consider are
kbd-macro-query and recursive-edit.

Here are some nesting situations, and what I suggest read-char should do
in each of them:

kmacro: get kmacro input
i-i=t: error
i-i=t, then kmacro: get kmacro input
kmacro, then i-i=t: error
i-i=t, kmacro, i-i=t: error
kmacro, i-i=t, kmacro: get inner kmacro input
kmacro, recursive-edit: get user input
i-i=t, recursive-edit: error
i-i=t, kmacro, recursive-edit: error
kmacro, i-i=t, recursive-edit: error

So basically, i-i=t means any request for user input should fail, which
my change achieves; but also, if i-i=t was bound *after* the kmacro,
then any request for kmacro input should also fail.  Not sure how to
achieve that.