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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 67837 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
Date: Fri, 15 Dec 2023 20:54:52 +0200

> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Fri, 15 Dec 2023 11:50:29 -0500
> 
> >From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Fri, 15 Dec 2023 11:39:24 -0500
> Subject: [PATCH] Make inhibit-interaction work properly with keyboard macros
> 
> Previously, inhibit-interaction=t prevented keyboard macros from
> running, even when those macros did not result in user interaction,
> since it was checked before the keyboard macro code had a chance to
> provide input.
> 
> Now, if there's a running keyboard macro which can provide input, that
> keyboard macro is allowed to provide input even if
> inhibit-interaction=t.  This is achieved by moving the check on
> inhibit-interaction to run after checking executing-kbd-macro in the
> low-level input handling mechanism, read_char.
> 
> inhibit-interaction also suppresses reading from stdin in batch mode,
> so we also must add a check on inhibit-interaction to
> read_minibuf_noninteractive, which again is only called after checking
> executing-kbd-macro.
> 
> * src/keyboard.c (read_char): Add call to
> barf_if_interaction_inhibited. (bug#67837)
> * src/lread.c (Fread_char, Fread_event, Fread_char_exclusive): Remove
> call to barf_if_interaction_inhibited.
> * src/minibuf.c (Fread_from_minibuffer): Remove call to
> barf_if_interaction_inhibited.
> (read_minibuf_noninteractive): Add call to barf_if_interaction_inhibited.

Please explain why you are removing the calls to
barf_if_interaction_inhibited from many functions.  It looks like they
will now do some work instead of barfing right at the beginning.  Why
is that TRT?

And I don't think I understand why we should care about a case when
inhibit-interaction is non-nil, and Emacs needs to execute a keyboard
macro, since executing keyboard macros is basically similar to
interactive invocations of commands.  What are the real-life use cases
for that?

> +    } else

This is against our style in C sources.

Previous Next

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