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

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Fri, 15 Dec 2023 16:49:02 UTC

Severity: normal

Merged with 65291

Found in versions 29.1.90, 30.0.50

Full log


Message #41 received at 67837 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, larsi <at> gnus.org, control <at> debbugs.gnu.org,
 67837 <at> debbugs.gnu.org
Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
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.

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

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.


        Stefan





This bug report was last modified 1 year and 118 days ago.

Previous Next


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