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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: larsi <at> gnus.org, 67837 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
Date: Sat, 16 Dec 2023 09:02:35 +0200

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: larsi <at> gnus.org,  67837 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Fri, 15 Dec 2023 15:09:59 -0500
> 
> > I'm saying that your proposal of fixing this will cause these
> > functions to do some parts of their jobs before they realize that they
> > can barf, and this will now happen even when they run not from a
> > keyboard macro, and even if the keyboard macro doesn't actually
> > provide any input.  This is definitely not TRT.  It affects use cases
> > completely unrelated to the ones you wanted to fix, and affects them
> > in adverse ways.
> 
> I think the effects on other use cases are only positive.  If, for
> example, read-char would fail due to reasons other than
> inhibit-interaction, it will now fail for those reasons.  Which is good,
> because it reduces the need for all code everywhere to think about the
> possibility that inhibit-interaction is non-nil.

Most calls don't signal errors, so the part that is important is when
they don't.

> > Please find a way of fixing the case of a keyboard macro that provides
> > input without adversely affecting the other cases where these
> > functions are called with inhibit-interaction=t.
> 
> How about if those original barf_if_interaction_inhibited calls only
> signal if executing-kbd-macro is nil?

We could perhaps do that, but see my other message: I think it is
fundamentally wrong to allow keyboard macros be exempt from this
feature.

> >> - Users write functions using keyboard macros and put them in hooks,
> >>   which happen to get invoked by packages which use inhibit-interaction.
> >>   Those functions don't actually require interaction, but because they
> >>   break, ultimately no code can use inhibit-interaction.
> >> 
> >> - I run tests in a batch Emacs, frequently using keyboard macros to
> >>   provide input.  Sometimes a bug causes code to run which calls
> >>   read-char outside of a keyboard macro.  I would like such read-char
> >>   calls to error (instead of hanging, which is what they do by default
> >>   in batch mode).  If I bind inhibit-interaction=t, then read-char will
> >>   exit with an error, but my keyboard macros will also immediately
> >>   error.
> >
> > In both cases, using a function would solve the problem.  So I'm not
> > convinced we need to support those marginal cases, unless you can come
> > up with a solution that will be both simple and will not affect
> > unrelated use cases.
> 
> - Are you suggesting that novice users should have to rewrite all their
>   keyboard macros in Lisp?  That sounds impractical.

I don't see anything impractical here.

> - How can I provide keyboard input to the interactive spec of a command
>   I am testing, other than by using keyboard macros?  I'd be pleased to
>   have an alternative solution.

Why do you need to do that when inhibit-interaction is non-nil in the
first place?  Code that needs interaction shouldn't be run or tested
in those conditions.

Previous Next

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