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

Previous Next

Full log

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

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

Eli Zaretskii <eliz <at> gnu.org> writes:
>> 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.

If that's the case, then could we add another variable which does behave
like I propose with these patches?  That is, it allows input from
keyboard macros, but not from the user?  That is personally what I want
in my packages, because it doesn't break users who use keyboard macros,
and it supports my use case of making read-char error in batch mode.

Or perhaps, another possible value of inhibit-interaction, which behaves
like that?

BTW, I'm curious to hear what Lars thinks, because I expect that
"keyboard macros should not work within inhibit-interaction=t" was not
at all part of the plan.

Although, I guess with my change, a keyboard macro which calls a
function which internally sets inhibit-interaction=t will effectively
ignore the inhibit-interaction setting.  Which is definitely not
correct.

The correct behavior is a bit subtle; also important to consider are
kbd-macro-query and recursive-edit.

Here are some nesting situations, and what I suggest read-char should do
in each of them:

kmacro: get kmacro input
i-i=t: error
i-i=t, then kmacro: get kmacro input
kmacro, then i-i=t: error
i-i=t, kmacro, i-i=t: error
kmacro, i-i=t, kmacro: get inner kmacro input
kmacro, recursive-edit: get user input
i-i=t, recursive-edit: error
i-i=t, kmacro, recursive-edit: error
kmacro, i-i=t, recursive-edit: error

So basically, i-i=t means any request for user input should fail, which
my change achieves; but also, if i-i=t was bound *after* the kmacro,
then any request for kmacro input should also fail.  Not sure how to
achieve that.

Previous Next

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