GNU bug report logs - #67837
29.1.90; inhibit-interaction breaks keyboard macros

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 67837 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
Date: Fri, 16 Feb 2024 17:26:45 -0500

Stefan Monnier <monnier <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.