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

[Spencer Baugh <sbaugh@janestreet.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Yes, I agree.  I'm interested in making this possible and willing to put
in the work to do it for the Emacs test suite.  (since it will help make
my own tests reliable)

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

What places are these?

I think that does sound like interaction to me.  In which case, could we
change those places to not use read-event?  Those places would break
anyway if they ran inside a user-defined keyboard macro, if I understand
correctly, so it's useful to fix them.