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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

merge 67837 65291
thanks

AFAICT this is the same bug as bug#65291 and the suggested patch is similar.

> 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.

I guess it begs the question: what is the purpose of
`inhibit-interaction`?

The way I see it, the purpose is to avoid Emacs waiting for user input
when we know there's no user, and thus signal an error if we ever get to
this point.

Basically, I think since our test suite runs just fine in batch, we
should be able to run it with inhibit-interaction=t as well (which
would fix annoying problems when some test fails and ends up waiting
for user input).

Note that trying to make the whole test suite runs with
`inhibit-interaction` non-nil is not at all straightforward, sadly:
there are several places where we do call things like `read-event`
without providing any keyboard input (i.e. without
`unread-command-event` or keyboard macros) and instead use a timeout
because this `read-event` is just there to force Emacs to wait while
some external process sends us some reply.  Should these be considered
"interaction"?  If not, then we open up a whole where some code may call
`read-event` with a relatively short timeout within a tight loop where
the purpose *is* to get user input and where the timeout is only present
to keep something else updated while we wait for that user's input.


        Stefan