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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sbaugh@janestreet.com,  larsi@gnus.org,  67837@debbugs.gnu.org,
>  control@debbugs.gnu.org
> Date: Sat, 16 Dec 2023 10:52:45 -0500
> 
> 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.

I agree.  And signaling an error could be useful for either aborting
some code which shouldn't interact with the user, or for catching the
error and doing something alternative to user interaction.  In the
latter case, disabling the error can actually break some code.

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

In general, yes.  But the test suite can also be run interactively,
and sometimes the ability to do so is very important for investigating
test failures.

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

I see no reason to insist that everything in the test suite _must_ be
runnable with inhibit-interaction non-nil.  The only purpose of the
test suite is to test whatever each test is testing, there are no
other requirements.  The code could be not very clean; if it does the
job, that is fine from where I stand.