From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Date: Sat, 16 Dec 2023 10:52:45 -0500 Message-ID: References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7599"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@janestreet.com, larsi@gnus.org, control@debbugs.gnu.org, 67837@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 16 16:53:26 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 1rEWyk-0001jL-Bw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Dec 2023 16:53:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEWyP-0000Nm-Ir; Sat, 16 Dec 2023 10:53:05 -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 1rEWyM-0000Mp-EM for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 10:53: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 1rEWyL-0007AU-0N for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 10:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rEWyL-0001OT-JU for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 10:53:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Dec 2023 15:53: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.17027419765339 (code B ref 67837); Sat, 16 Dec 2023 15:53:01 +0000 Original-Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 15:52:56 +0000 Original-Received: from localhost ([127.0.0.1]:55802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEWyG-0001O2-2X for submit@debbugs.gnu.org; Sat, 16 Dec 2023 10:52:56 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEWyD-0001Nl-KI; Sat, 16 Dec 2023 10:52:54 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8EB45100068; Sat, 16 Dec 2023 10:52:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702741966; bh=y3TunpwzOogYXMRijDfv+4WgoZgt6MZMom8n6ftW0I0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GgxewbU3gaZaRpW1NxSgrqXlXLQxRCxJ3pE5EApiuN1FqBlsSDcys6LYbpw/H8O8t PN3E9ta5xbk3RY8wDJRwVJFYGUC8aZC9jOZykR/8ze2V3hUVAp/R8daFURDmBulS/v Z1Qb3xDlSV4LmhN8Myj7yiTCUjLknDTou7UhkKB3Giw0RvSeSc+bjuw0CISfAIExWG f0DT46qGbDmUuKoMiuy3l7eRgxjYLvaK6N1I5AO3NIw7rmyrE79ID16PkapnG500vN ZoUBfAGD+XdCYcazwFX0BgBozSezsG+L9Rkc2s7xiB0P1WEXMEfP+OYfU91tPS4dJh 652+cFBGl85yw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A11CA100033; Sat, 16 Dec 2023 10:52:46 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 69E4A12023C; Sat, 16 Dec 2023 10:52:46 -0500 (EST) 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:276359 Archived-At: merge 67837 65291 thanks AFAICT this is the same bug as bug#65291 and the suggested patch is similar. > 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. I guess it begs the question: what is the purpose of `inhibit-interaction`? The way I see it, the purpose is to avoid Emacs waiting for user input when we know there's no user, and thus signal an error if we ever get to this point. Basically, I think since our test suite runs just fine in batch, we should be able to run it with inhibit-interaction=t as well (which would fix annoying problems when some test fails and ends up waiting for user input). Note that trying to make the whole test suite runs with `inhibit-interaction` non-nil is not at all straightforward, sadly: there are several places where we do call things like `read-event` without providing any keyboard input (i.e. without `unread-command-event` or keyboard macros) and instead use a timeout because this `read-event` is just there to force Emacs to wait while some external process sends us some reply. Should these be considered "interaction"? If not, then we open up a whole where some code may call `read-event` with a relatively short timeout within a tight loop where the purpose *is* to get user input and where the timeout is only present to keep something else updated while we wait for that user's input. Stefan