From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Date: Fri, 15 Dec 2023 15:39:31 -0500 Message-ID: References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23102"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 15 21:40:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rEEyv-0005mE-93 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Dec 2023 21:40:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEEya-0005q2-8f; Fri, 15 Dec 2023 15:40:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEEyY-0005pJ-Fi for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 15:40:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rEEyY-0007g4-6x for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 15:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rEEyY-00061O-0q for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 15:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Dec 2023 20:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs Original-Received: via spool by 67837-submit@debbugs.gnu.org id=B67837.170267278023107 (code B ref 67837); Fri, 15 Dec 2023 20:40:01 +0000 Original-Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 20:39:40 +0000 Original-Received: from localhost ([127.0.0.1]:53606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEEyC-00060d-7c for submit@debbugs.gnu.org; Fri, 15 Dec 2023 15:39:40 -0500 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:36247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEEy9-00060O-Bi for 67837@debbugs.gnu.org; Fri, 15 Dec 2023 15:39:38 -0500 In-Reply-To: <83h6kjnrzg.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:276287 Archived-At: Eli Zaretskii writes: >> Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Fri, 15 Dec 2023 22:01:01 +0200 >> From: Eli Zaretskii >> >> > 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.