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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sbaugh@janestreet.com,  larsi@gnus.org,  67837@debbugs.gnu.org
> Date: Sat, 17 Feb 2024 10:15:39 -0500
> 
> >> 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.

<Rolls the eyes> So now we need to pay for the strange ways you run
the test suite?

> Also, there's the problem of having to decide whether it's hanging
> or whether it's just slow.

That is never a problem for me: just look at the "top" display or
similar.

> Also, killing the hung Emacs process allows further tests to be run,
> whereas `C-c` would interrupt the whole testsuite.

Not necessarily.  IME, it usually interrupts only the test that's
being run.

> And of course, there's also the CI case where there really is noone
> to hit `C-c`.

Maybe we should ask Michael, but AFAIK CI frameworks are prepared to
deal with such contingencies.

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

If you exit the process, then I agree, the rest is not important.  But
exiting is too drastic, and will be frowned upon, so we shouldn't do
that.  And if we only signal an error, then any code that runs before
it could have effect that previously didn't happen -- that's the
scenario I'm thinking of.

> > 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?  🙂

No.  Risking breakage when adding new useful features is justified.
Risking breakage to cater to oddball use cases isn't.  Emacs is still
being developed, but it isn't a student project, where people should
be free to experiment all they like.  We have users out there who rely
on us to not destabilize Emacs unless we absolutely have to, for much
greater good.