bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
Date: Fri, 15 Dec 2023 20:54:52 +0200

> Cc: Lars Ingebrigtsen <larsi@gnus.org>
> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 15 Dec 2023 11:50:29 -0500
> 
> >From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]