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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

That works if you started the test suite directly from the command line
"in the foreground", but I usually run it in the background detached from
the tty.
Also, there's the problem of having to decide whether it's hanging
or whether it's just slow.
Also, killing the hung Emacs process allows further tests to be run,
whereas `C-c` would interrupt the whole testsuite.
And of course, there's also the CI case where there really is noone
to hit `C-c`.

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

Sorry, it's still too vague for me to understand what kind of scenario
you're thinking if.

For me, when we hit this error the only important thing to do is to
report the problem and stop what we're doing.  Rather than signal a Lisp
error, I'd be OK with exiting the process.  So the details of exactly
when&where the error is signaled don't seem very relevant.

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

Thanks.  I don't see anything in these examples that shows they depend
on the specific way the code currently works.  Maybe for `bug#25214` we
wouldn't want to exit the process altogether, but for everything else,
the use case seems pretty much exactly the same as mine, with the same
overarching goal: report the problem and stop what we're doing.

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

Should we rename Emacs-29.2 as Emacs-final, then?  🙂

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

Of course.  That's why I've been sitting on this `sit-for` change
without reporting the problem, waiting to find a more real case
where it bites us.


        Stefan