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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sbaugh@janestreet.com,  larsi@gnus.org,  67837@debbugs.gnu.org
> Date: Sat, 17 Feb 2024 09:13:07 -0500
> 
> > I'm mostly opposed to making this kind of changes for reasons that are
> > very weak, and basically are based on a special use case Spencer
> > bumped into in his practice, a use case that can be resolved in a
> > different way without any changes.
> 
> I can't remember what Spencer's use case was, but for me the use case
> was simply that I was getting tired of having to kill Emacs processes
> that were hanging waiting for input while running the test suite.

?? I bump into this from time to time, but a simple Ctrl-C usually
solves the problem on the spot.

>     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.
> 
> Why are you concerned?  Which code do you think will break?

The code which doesn't expect some of the jobs of those functions to
be done when they eventually signal an error.

> More specifically, have you ever seen or heard about a piece of code
> using `inhibit-interaction`?  I have not, *except* in the context of
> bugs like this one.  IOW, AFAICT, `inhibit-interaction` fails at
> providing the only feature for which it's useful.

See bug#13697, which was the motivation for introducing this variable.
It mentions a couple of use cases, bug#6567 and bug#25214.

> We have a kind of a mess when it comes to waiting for external events:
> if you look at various pieces of code that have to do such waits, you'll
> tend to see that they all do it a bit differently, and if you look at
> the surrounding comments and Git history, you'll tend to see that it's
> the result of frustrating trial-and-failure bumping into various corner
> cases.  The fact that `sit-for` currently allows async processes in
> interactive mode but not in batch mode is probably one of the sources of
> such problems.

I agree that we have a mess, but disagree that we should try to fix
it.  It's a mess we have been living with for decades, and I don't
doubt that gobs of programs out there depend on this mess.

> > With all due respect to our test suite, let's not forget that its main
> > purpose is to allow us to test the various Emacs features.
> 
> That doesn't mean that problems encountered while writing the test suite
> (e.g. the fact that `sit-for` doesn't read from async processes when
> used in batch) can't reflect real problems that also affect real code
> and thus deserve changes in Emacs proper.

Yes, but we need to be able to define those real problems.  Just the
fact that something interferes with the test suite itself is not
enough.