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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 16 Dec 2023 15:57:42 +0200

> From: [email-masked]
> Date: Sat, 16 Dec 2023 13:22:23 +0000 (UTC)
> Cc: Spencer Baugh <[email-masked]>, [email-masked],
> 	[email-masked], [email-masked]
> 
> Eli Zaretskii <[email-masked]> writes:
> > Why do you need to do that when inhibit-interaction is non-nil in the
> > first place?  Code that needs interaction shouldn't be run or tested
> > in those conditions.
> 
> As I said before: because otherwise read-char outside a keyboard macro
> will hang, and I want my test to fail instead of hang in that case.

The usual way of dealing with this in test frameworks is to mock
read-char (or whatever function that causes trouble when running
tests).  As long as read-char is not the API you are testing, you
don't really need read-char as it works in Emacs, you need something
that will provide the same output.

> Let me phrase the use case differently:
> 
> I have some tests which I'd like to run in batch Emacs.  By default, if
> any of the code under test runs read-char, Emacs will simply hang
> forever (that's what read-char does in batch mode).
> 
> I would prefer instead that my tests to fail immediately if any code
> runs read-char.  How would you suggest I do that?

Define a replacement read-char in the test harness that accepts the
same arguments and signals an error.