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, 17 Feb 2024 09:53:33 +0200 Message-ID: <86frxrv85e.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="33128"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, larsi@gnus.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 Feb 17 08:55:04 2024 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 1rbFXM-0008Oz-Ix for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Feb 2024 08:55:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rbFX1-0007LN-Ev; Sat, 17 Feb 2024 02:54:43 -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 1rbFX0-0007LE-S2 for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2024 02:54:42 -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 1rbFX0-00020S-Jx for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2024 02:54:42 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rbFXK-0004hj-AS for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2024 02:55: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, 17 Feb 2024 07:55: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.170815644518018 (code B ref 67837); Sat, 17 Feb 2024 07:55:02 +0000 Original-Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 07:54:05 +0000 Original-Received: from localhost ([127.0.0.1]:60376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFWP-0004gY-8W for submit@debbugs.gnu.org; Sat, 17 Feb 2024 02:54:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFWN-0004g3-77 for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 02:54:04 -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 1rbFVx-0001wZ-2t; Sat, 17 Feb 2024 02:53:37 -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=4jolFUWWJGhKMc6x+nX5kVlH1gWCJbHYPFLr2AYUYwc=; b=Xc94PkfI6oaj 6+EywdwqHFQa95M3w9LjqL5G9dbd8mJvOqWAJoTYGkO77j3m3n0CIRmSeRLVEEMxs3Pwu1owfyfdz Co+0bzG2IoOGpwS2ujU5SS9/gvx8Dxl+iwH/SuZ/qwEe1uf/B/zWWIrW3B+G9WDZYjt8GlxKdkvFx fLqOcDiLHtY4qLfTL9j2EQRSQ7zQ7LFF1qa7UMWH5Htd573D5dsCRDsaxkX4Yyt5ZiWQCLu3Mmyh7 5rs0iZThFuDFpTptwvm0C0fmVkry8eiQgjsdH3fkl9wGQVDcSR3lMGKm70FXOizT6QiFs//itEh6d S2M6Hz3pElu4vmhw6xIOPg==; In-Reply-To: (message from Stefan Monnier on Fri, 16 Feb 2024 18:27:44 -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:280114 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , larsi@gnus.org, 67837@debbugs.gnu.org > Date: Fri, 16 Feb 2024 18:27:44 -0500 > > IIUC, Eli is opposed to changing the behavior of `inhibit-interaction`, I'm mostly opposed to making this kind of changes for reasons that are very weak, and basically are based on a special use case Spencer bumped into in his practice, a use case that can be resolved in a different way without any changes. I'm talking about Spencer's code which uses keyboard macros for mocking user input. I've seen no other justification for these behavior changes. > If you're interested, here's my WiP patch (which modifies the way > `inhibit-interaction` behaves). > > The most delicate point might be the change to `sit-for` in batch mode: > I don't have a clear idea why we use `sleep-for` there and what is the > impact of using `read-event` instead. Frankly, I don't understand the underlying ideas here. And it seems to include unrelated change(s)? E.g., what is this about: > + defsubr (&Sadjust_point_for_property); > + DEFVAR_LISP ("point-adjustment-function", > + Vpoint_adjustment_function, > + doc: /* Function called to adjust point after commands. > +This function is run after each command that moved point, > +unless `disable-point-adjustment' or `global-disable-point-adjustment' > +is non-nil. */); > + Vpoint_adjustment_function = intern ("adjust-point-for-property"); ? > diff --git a/test/lisp/autorevert-tests.el b/test/lisp/autorevert-tests.el > index c202970e0b2..58002d597f0 100644 > --- a/test/lisp/autorevert-tests.el > +++ b/test/lisp/autorevert-tests.el > @@ -110,7 +110,7 @@ auto-revert--wait-for-revert > (if (and (or file-notify--library > (file-remote-p temporary-file-directory)) > (with-current-buffer buffer auto-revert-use-notify)) > - (read-event nil nil 0.05) > + (sit-for 0.05) > (sleep-for 0.05))))) So we are supposed to replace all calls to read-event in our test suite with sit-for, and to be able to do that, we are now changing how sit-for behaves in non-interactive sessions? That sounds like a very serious incompatible change in behavior for a very weak reason -- the possibility to run the test suite with inhibit-interaction non-nil. I sincerely hope we will not make such changes for such reasons. If we do, we shouldn't be surprised that Emacs' stability does not improve with newer releases. With all due respect to our test suite, let's not forget that its main purpose is to allow us to test the various Emacs features. How we do that and whether we do it cleanly or not is completely unimportant, as long as the features get tested and tested well. It follows that the needs of the test suite should generally not require any infrastructure changes in Emacs; instead, we should jump through as many hoops as needed to test Emacs as it is.