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: 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: Fri, 15 Dec 2023 22:14:11 +0200

> Cc: larsi <at> gnus.org, 67837 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Fri, 15 Dec 2023 22:01:01 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > This allows the keyboard macro is allowed to provide input even if
> > inhibit-interaction=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.

I'm actually tend to think that this proposal is fundamentally wrong,
not just problematic implementation-wise.  Providing input from a
keyboard macro is still input, and inhibit-interaction=t means asking
for input signals an error.  So your suggestion subverts this feature,
and therefore it is simply wrong to install something like that.

IOW, signaling an error in these cases is exactly TRT, and we should
not let keyboard macros circumvent this mechanism.

Previous Next

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