From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Date: Sat, 16 Dec 2023 18:08:58 +0200 Message-ID: <83sf42ku3p.fsf@gnu.org> References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9603"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, larsi@gnus.org, control@debbugs.gnu.org, 67837@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 16 17:10:32 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 1rEXFH-0002Ia-SX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Dec 2023 17:10:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEXEs-0002XD-2m; Sat, 16 Dec 2023 11:10:06 -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 1rEXEn-0002Wk-R7 for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 11:10:03 -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 1rEXEn-0002gM-Hb for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 11:10:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rEXEo-0004Sy-5u for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 11:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Dec 2023 16:10:02 +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.170274296717111 (code B ref 67837); Sat, 16 Dec 2023 16:10:02 +0000 Original-Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 16:09:27 +0000 Original-Received: from localhost ([127.0.0.1]:55855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEXEF-0004Rp-3D for submit@debbugs.gnu.org; Sat, 16 Dec 2023 11:09:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEXEC-0004RW-Gh; Sat, 16 Dec 2023 11:09:25 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEXE4-0002av-V5; Sat, 16 Dec 2023 11:09:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MFivxPJs8KBc5sRSFuMgi7FDyEezACqv1eo6cHLY9tc=; b=XirY82P38+Wi BOWzOv6lcVSkS0tyfpizG53kZlC+8Vj0xg8r6oDcgDPQqklPyyPSm4kTnDd7Y4E4ATV4JoK/dqSxy x0TxcPXUKXLl+e5FFK3jEK5NDU6BE8Ippp3etZF5CT3qevFCy5pnFVMkwEx9jBoX+iSGguJUOzdAx 04Hmr+3cOwMAsIzCQI0n+hrntRPBUz8jmsC+OBFHHF+ETC+0nmssikVKXgcwTHaxNaBtphiJiPLtG hq0vG963RoF25972P0gGN7cDmzaoStVsaVnLarJsRe5ybPNnVnPoYqNVbbj9S0SW8F8jt/YEF13Yc gDQQBGbi8HIpxJo7frBFwg==; In-Reply-To: (message from Stefan Monnier on Sat, 16 Dec 2023 10:52:45 -0500) 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:276362 Archived-At: > From: Stefan Monnier > Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org, > control@debbugs.gnu.org > Date: Sat, 16 Dec 2023 10:52:45 -0500 > > 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. I agree. And signaling an error could be useful for either aborting some code which shouldn't interact with the user, or for catching the error and doing something alternative to user interaction. In the latter case, disabling the error can actually break some code. > 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). In general, yes. But the test suite can also be run interactively, and sometimes the ability to do so is very important for investigating test failures. > 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. I see no reason to insist that everything in the test suite _must_ be runnable with inhibit-interaction non-nil. The only purpose of the test suite is to test whatever each test is testing, there are no other requirements. The code could be not very clean; if it does the job, that is fine from where I stand.