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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  67837@debbugs.gnu.org
> Date: Fri, 16 Feb 2024 17:26:45 -0500
> 
> 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.

Alas, bug#65291 doesn't have any justification for the change, so I
agree that they should be merged, but doing so doesn't add any useful
information to this discussion, IMO.

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

And I'm still concerned that making these changes will be an
incompatible change, because the functions that signaled the error
right at the beginning will now do part of their job before signaling,
and that could affect the net result of calling them in those cases.

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

Btw, I think calling read-event with a timeout should not signal an
error when interaction-inhibited is non-nil.

But more generally, the above issues with our test suite are examples
of non-trivial code which could be affected by the proposed changes.
The justifications for these changes that were presented until now,
such as they are, are very weak, and I therefore still object to
making them, because the use cases where those changes are supposed to
be useful can be taken care of by other means, like API mocking.

>From where I stand, this is another example of taking marginal obscure
use cases and promoting them to the level of a general problem that
needs significant low-level changes whose effect is
backward-incompatible behavior changes.  Instead, those use cases
should be handled with other techniques already available in Emacs
that don't require any changes to our infrastructure.