X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Spencer Baugh <sbaugh@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 16:49:02 +0000 Resent-Message-ID: <handler.67837.B.170265892311059 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: report 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 67837 <at> debbugs.gnu.org Cc: Lars Ingebrigtsen <larsi@HIDDEN> X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN Received: via spool by submit <at> debbugs.gnu.org id=B.170265892311059 (code B ref -1); Fri, 15 Dec 2023 16:49:02 +0000 Received: (at submit) by debbugs.gnu.org; 15 Dec 2023 16:48:43 +0000 Received: from localhost ([127.0.0.1]:53397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEBMf-0002sB-Qh for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 11:48:43 -0500 Received: from lists.gnu.org ([2001:470:142::17]:46394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rEBMc-0002rJ-Pl for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 11:48:40 -0500 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 <sbaugh@HIDDEN>) id 1rEBMX-0002ed-GE for bug-gnu-emacs@HIDDEN; Fri, 15 Dec 2023 11:48:33 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>) id 1rEBMT-0003ke-7p for bug-gnu-emacs@HIDDEN; Fri, 15 Dec 2023 11:48:33 -0500 From: Spencer Baugh <sbaugh@HIDDEN> Date: Fri, 15 Dec 2023 11:48:27 -0500 Message-ID: <ieredfnl8dg.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) If we run a keyboard macro (including ones which never interact with the user) while inhibit-interaction=t, and the keyboard macro invokes anything which reads input (which can be provided by the keyboard macro), then the keyboard macro will error. For example: (let ((inhibit-interaction t)) (execute-kbd-macro (read-kbd-macro "M-: 1 RET"))) So, for example, if a user has defined a function using keyboard macros, and that function is invoked within inhibit-interaction=t, the function will unnecessarily fail. This is because inhibit-interaction is checked too early: it should be checked after the keyboard macro code has a chance to provide input. A patch which does this follows. In GNU Emacs 29.1.90 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2023-12-14 built on igm-qws-u22796a Repository revision: 57fa5a53f74e489702825045832f52730c5d550f Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.9 (Green Obsidian) Configured using: 'configure --config-cache --with-x-toolkit=lucid --with-gif=ifavailable' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Magit Minor modes in effect: delete-selection-mode: t global-so-long-mode: t pixel-scroll-precision-mode: t jane-fe-minor-mode: t editorconfig-mode: t which-function-mode: t global-git-commit-mode: t magit-auto-revert-mode: t shell-dirtrack-mode: t server-mode: t windmove-mode: t savehist-mode: t save-place-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tab-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t context-menu-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane/packages hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane-dap/packages /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane/config hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane-dap/config /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane/config hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane-fzf/config /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane/packages hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane-fzf/packages /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/jane/packages hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/spacemacs-layers/org-fe/packages /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-types hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-types /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-macros hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-macros /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-repeat hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-repeat /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-search hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-search /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-commands hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-commands /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-test-helpers hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-test-helpers /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-command-window hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-command-window /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-common hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-common /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-jumps hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-jumps /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-ex hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-ex /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-pkg hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-pkg /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-digraphs hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-digraphs /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-integration hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-integration /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-vars hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-vars /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-maps hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-maps /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-core hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-core /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-tests hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-tests /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/evil/evil-states hides /home/sbaugh/.emacs.d/elpa/evil-1.15.0/evil-states /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/csharp-mode hides /home/sbaugh/src/emacs/emacs-29/lisp/progmodes/csharp-mode /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/xref hides /home/sbaugh/src/emacs/emacs-29/lisp/progmodes/xref /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/project hides /home/sbaugh/src/emacs/emacs-29/lisp/progmodes/project /home/sbaugh/.emacs.d/elpa/popup-0.5.9/popup-autoloads hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/popup/popup-autoloads /home/sbaugh/.emacs.d/elpa/popup-0.5.9/popup hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/popup/popup /home/sbaugh/.emacs.d/elpa/async-1.9.7/dired-async hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/async/dired-async /home/sbaugh/.emacs.d/elpa/async-1.9.7/async hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/async/async /home/sbaugh/.emacs.d/elpa/async-1.9.7/smtpmail-async hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/async/smtpmail-async /home/sbaugh/.emacs.d/elpa/async-1.9.7/async-test hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/async/async-test /home/sbaugh/.emacs.d/elpa/async-1.9.7/async-bytecomp hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/async/async-bytecomp /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/auctex/lpath hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/dictionary/lpath /home/sbaugh/src/emacs/emacs-29/lisp/net/dictionary hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/dictionary/dictionary /home/sbaugh/src/emacs/emacs-29/lisp/progmodes/eglot hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/eglot/eglot /home/sbaugh/src/emacs/emacs-29/lisp/external-completion hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/eglot/external-completion /home/sbaugh/src/emacs/emacs-29/lisp/jsonrpc hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/eglot/jsonrpc /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/caml-font hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/ocaml/caml-font /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-autoloads hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-autoloads /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-imenu hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-imenu /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-grep hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-grep /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-mode hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-mode /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-files hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-files /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-net hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-net /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-semantic hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-semantic /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-ring hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-ring /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-help hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-help /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-regexp hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-regexp /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-locate hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-locate /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-utils hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-utils /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-misc hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-misc /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-types hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-types /home/sbaugh/.emacs.d/elpa/helm-core-3.9.0/helm-source hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-source /home/sbaugh/.emacs.d/elpa/helm-core-3.9.0/helm hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-eval hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-eval /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-elisp hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-elisp /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-command hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-command /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-bookmark hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-bookmark /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-info hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-info /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-elisp-package hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-elisp-package /home/sbaugh/.emacs.d/elpa/helm-core-3.9.0/helm-lib hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-lib /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-comint hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-comint /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-id-utils hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-id-utils /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-sys hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-sys /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-color hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-color /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-eshell hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-eshell /home/sbaugh/.emacs.d/elpa/helm-core-3.9.0/helm-core hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-core /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-x-files hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-x-files /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-shell hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-shell /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-tags hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-tags /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-for-files hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-for-files /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-find hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-find /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-font hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-font /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-dabbrev hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-dabbrev /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-epa hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-epa /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-config hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-config /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-easymenu hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-easymenu /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-global-bindings hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-global-bindings /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-external hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-external /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-occur hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-occur /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-man hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-man /home/sbaugh/.emacs.d/elpa/helm-core-3.9.0/helm-multi-match hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-multi-match /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-buffers hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-buffers /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-fd hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-fd /home/sbaugh/.emacs.d/elpa/helm-3.9.0/helm-adaptive hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/helm/helm-adaptive /home/sbaugh/.emacs.d/elpa/dash-2.19.1/dash hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/dash/dash /home/sbaugh/.emacs.d/elpa/dash-2.19.1/dash-functional hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/dash/dash-functional /home/sbaugh/.emacs.d/elpa/ivy-0.14.0/colir hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/swiper/colir /home/sbaugh/.emacs.d/elpa/ivy-0.14.0/ivy hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/swiper/ivy /home/sbaugh/.emacs.d/elpa/ivy-0.14.0/ivy-overlay hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/swiper/ivy-overlay /home/sbaugh/.emacs.d/elpa/ivy-0.14.0/ivy-faces hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/swiper/ivy-faces /home/sbaugh/.emacs.d/elpa/with-editor-3.2.0/with-editor hides /usr/local/home/sbaugh/workspaces/fe-310581/+share+/app/emacs/elisp/contrib/with-editor/lisp/with-editor Features: (shadow sort mail-extr emacsbug goto-addr vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view vc-dir shortdoc pcmpl-unix pcmpl-gnu etags fileloop magit-imenu git-rebase face-remap pulse vc-fe vc-hg vc cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs vc-git vc-dispatcher misc dabbrev misearch multi-isearch help-fns radix-tree cl-print macros sh-script treesit executable bug-reference dired-aux org-element org-persist org-id org-refile avl-tree generator oc-basic ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range gnus-win ol-docview doc-view jka-compr image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi let-alist delsel so-long jane-fe-read-feature pixel-scroll cua-base tramp tramp-loaddefs trampver tramp-integration tramp-compat parse-time iso8601 ffap jane-merlin merlin-imenu merlin-xref merlin-cap merlin jane-async-merlin jane-completion grep jane-common site-start jane-customization jane-comint org-protocol jane-fe-project xref files-x jane-fe-menu ecaml_plugin view gopcaml magit-bookmark bookmark image+ advice image-file image-converter editorconfig editorconfig-core editorconfig-core-handle editorconfig-fnmatch whitespace jane-auto-modes vba-mode markdown-mode color jane jane-yasnippet jane-micro-features ert ewoc debug backtrace jane-diff unified-test-mode shell-file core core-buffer core-error jane-sexp jane-python jane-ocaml jane-tuareg-theme tuareg tuareg-compat tuareg-opam skeleton flymake-proc flymake warnings thingatpt smie caml-types caml-help caml-emacs find-file compile jane-cr jane-codeium jane-align jane-deprecated jane-smerge gnu-elpa-keyring-update jane-ocp-indent ocp-indent jane-eglot yasnippet-autoloads swiper-autoloads htmlize-autoloads eglot-autoloads editorconfig-autoloads codeium-autoloads jane-autoloads jane-util ob-shell page-ext dired-x magit-extras project magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff diff-mode git-commit log-edit message sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor shell server magit-mode transient edmacro kmacro magit-git magit-section magit-utils crm dash gnus nnheader gnus-util text-property-search mail-utils range mm-util mail-prsvr cl-extra help-mode windmove org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete org-list org-footnote org-faces org-entities time-date noutline outline ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx org-fold org-fold-core org-keys oc org-loaddefs find-func cal-menu calendar cal-loaddefs org-version org-compat org-macs format-spec gdb-mi bindat gud easy-mmode comint ansi-osc ansi-color ring vundo modus-vivendi-theme modus-themes pcase savehist saveplace cus-edit pp cus-load icons wid-edit adaptive-wrap-autoloads csv-mode-autoloads cyberpunk-theme-autoloads evil-autoloads exwm-autoloads helm-autoloads helm-core-autoloads async-autoloads ivy-autoloads magit-autoloads git-commit-autoloads finder-inf magit-section-autoloads dash-autoloads popup-autoloads url-http-ntlm-autoloads url-auth vc-hgcmd-autoloads vundo-autoloads info with-editor-autoloads xelb-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo x-toolkit xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 811046 110142) (symbols 48 53807 0) (strings 32 189876 13112) (string-bytes 1 7243691) (vectors 16 87904) (vector-slots 8 1801483 167316) (floats 8 601 738) (intervals 56 17985 1740) (buffers 976 53))
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Spencer Baugh <sbaugh@HIDDEN> Subject: bug#67837: Acknowledgement (29.1.90; inhibit-interaction breaks keyboard macros) Message-ID: <handler.67837.B.170265892311059.ack <at> debbugs.gnu.org> References: <ieredfnl8dg.fsf@HIDDEN> X-Gnu-PR-Message: ack 67837 X-Gnu-PR-Package: emacs Reply-To: 67837 <at> debbugs.gnu.org Date: Fri, 15 Dec 2023 16:49:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 67837 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 67837: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D67837 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Spencer Baugh <sbaugh@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 16:51:02 +0000 Resent-Message-ID: <handler.67837.B67837.170265903711302 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 67837 <at> debbugs.gnu.org Cc: Lars Ingebrigtsen <larsi@HIDDEN> Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170265903711302 (code B ref 67837); Fri, 15 Dec 2023 16:51:02 +0000 Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 16:50:37 +0000 Received: from localhost ([127.0.0.1]:53402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEBOW-0002wD-RU for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 11:50:37 -0500 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:36407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rEBOV-0002vx-1Z for 67837 <at> debbugs.gnu.org; Fri, 15 Dec 2023 11:50:35 -0500 From: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ieredfnl8dg.fsf@HIDDEN> (Spencer Baugh's message of "Fri, 15 Dec 2023 11:48:27 -0500") References: <ieredfnl8dg.fsf@HIDDEN> Date: Fri, 15 Dec 2023 11:50:29 -0500 Message-ID: <ierbkarl8a2.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Patch to fix: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Make-inhibit-interaction-work-properly-with-keyboard.patch From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001 From: Spencer Baugh <sbaugh@HIDDEN> Date: Fri, 15 Dec 2023 11:39:24 -0500 Subject: [PATCH] Make inhibit-interaction work properly with keyboard macros Previously, inhibit-interaction=t prevented keyboard macros from running, even when those macros did not result in user interaction, since it was checked before the keyboard macro code had a chance to provide input. Now, if there's a running keyboard macro which can provide input, that keyboard macro is allowed to provide input even if inhibit-interaction=t. This is achieved by moving the check on inhibit-interaction to run after checking executing-kbd-macro in the low-level input handling mechanism, read_char. inhibit-interaction also suppresses reading from stdin in batch mode, so we also must add a check on inhibit-interaction to read_minibuf_noninteractive, which again is only called after checking executing-kbd-macro. * src/keyboard.c (read_char): Add call to barf_if_interaction_inhibited. (bug#67837) * src/lread.c (Fread_char, Fread_event, Fread_char_exclusive): Remove call to barf_if_interaction_inhibited. * src/minibuf.c (Fread_from_minibuffer): Remove call to barf_if_interaction_inhibited. (read_minibuf_noninteractive): Add call to barf_if_interaction_inhibited. --- src/keyboard.c | 5 ++++- src/lread.c | 6 ------ src/minibuf.c | 5 +++-- 3 files changed, 7 insertions(+), 9 deletions(-) diff --git a/src/keyboard.c b/src/keyboard.c index 81605e75ba2..9ec39c89699 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -2632,7 +2632,10 @@ read_char (int commandflag, Lisp_Object map, executing_kbd_macro_index++; goto from_macro; - } + } else + /* Getting input from a keyboard macro doesn't count as + interacting with the user. */ + barf_if_interaction_inhibited (); if (!NILP (unread_switch_frame)) { diff --git a/src/lread.c b/src/lread.c index 255b6e914d9..154c751cbe9 100644 --- a/src/lread.c +++ b/src/lread.c @@ -950,8 +950,6 @@ DEFUN ("read-char", Fread_char, Sread_char, 0, 3, 0, { Lisp_Object val; - barf_if_interaction_inhibited (); - if (! NILP (prompt)) { cancel_echoing (); @@ -988,8 +986,6 @@ DEFUN ("read-event", Fread_event, Sread_event, 0, 3, 0, `inhibited-interaction' error. */) (Lisp_Object prompt, Lisp_Object inherit_input_method, Lisp_Object seconds) { - barf_if_interaction_inhibited (); - if (! NILP (prompt)) { cancel_echoing (); @@ -1027,8 +1023,6 @@ DEFUN ("read-char-exclusive", Fread_char_exclusive, Sread_char_exclusive, 0, 3, { Lisp_Object val; - barf_if_interaction_inhibited (); - if (! NILP (prompt)) { cancel_echoing (); diff --git a/src/minibuf.c b/src/minibuf.c index 58adde1bf66..bf21a8d9cad 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -316,6 +316,9 @@ read_minibuf_noninteractive (Lisp_Object prompt, bool expflag, struct emacs_tty etty; bool etty_valid UNINIT; + /* inhibit-interaction also prevents reading from stdin. */ + barf_if_interaction_inhibited (); + /* Check, whether we need to suppress echoing. */ if (CHARACTERP (Vread_hide_char)) hide_char = XFIXNAT (Vread_hide_char); @@ -1344,8 +1347,6 @@ DEFUN ("read-from-minibuffer", Fread_from_minibuffer, { Lisp_Object histvar, histpos, val; - barf_if_interaction_inhibited (); - CHECK_STRING (prompt); if (NILP (keymap)) keymap = Vminibuffer_local_map; -- 2.39.3 --=-=-=--
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Eli Zaretskii <eliz@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 18:56:01 +0000 Resent-Message-ID: <handler.67837.B67837.17026665105863 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh <sbaugh@HIDDEN>, Stefan Monnier <monnier@HIDDEN> Cc: 67837 <at> debbugs.gnu.org, larsi@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.17026665105863 (code B ref 67837); Fri, 15 Dec 2023 18:56:01 +0000 Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 18:55:10 +0000 Received: from localhost ([127.0.0.1]:53456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEDL3-0001WU-Lt for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 13:55:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rEDL1-0001WD-4x for 67837 <at> debbugs.gnu.org; Fri, 15 Dec 2023 13:55:08 -0500 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 <eliz@HIDDEN>) id 1rEDKu-0006kV-Ok; Fri, 15 Dec 2023 13:55:00 -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=B6tr27ZHcjJSen5cRJ7HjUms5zmmaExlZ4TIz+9IpBg=; b=US5LtDJlMuV9 bAQ6844YY+NwloHepnM5fAkZ5H92vzIm7svFd711Sx0LuDYVh+zgVe5IVne1jHsL6nlTV+Fk68ZKY FDsinc/tErTpM0YpmZYA5JTP8N/NC8gI8/mHrh5AQCx+USR44Y2tcHc5RqOqCESmiE3rAs7RsoUNd Vp9ZCdQ+SYZbazF85gsMw4yIzavC68596YSR+KhG+4LxYUHQXHLguP4030QQhZDCSXd9p5xxdLvv3 Eaja5p2vJVVpJSacjc4wW0IgwjCrGlaZPt5beTLo8JCqJLEF3e6Sr0MCqc/M7Kzp63wfHOdgMU7au b6+yYAxoY8EAOC3P0F5IMQ==; Date: Fri, 15 Dec 2023 20:54:52 +0200 Message-Id: <83le9vnvnn.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> In-Reply-To: <ierbkarl8a2.fsf@HIDDEN> (message from Spencer Baugh on Fri, 15 Dec 2023 11:50:29 -0500) References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Lars Ingebrigtsen <larsi@HIDDEN> > From: Spencer Baugh <sbaugh@HIDDEN> > Date: Fri, 15 Dec 2023 11:50:29 -0500 > > >From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001 > From: Spencer Baugh <sbaugh@HIDDEN> > Date: Fri, 15 Dec 2023 11:39:24 -0500 > Subject: [PATCH] Make inhibit-interaction work properly with keyboard macros > > Previously, inhibit-interaction=t prevented keyboard macros from > running, even when those macros did not result in user interaction, > since it was checked before the keyboard macro code had a chance to > provide input. > > Now, if there's a running keyboard macro which can provide input, that > keyboard macro is allowed to provide input even if > inhibit-interaction=t. This is achieved by moving the check on > inhibit-interaction to run after checking executing-kbd-macro in the > low-level input handling mechanism, read_char. > > inhibit-interaction also suppresses reading from stdin in batch mode, > so we also must add a check on inhibit-interaction to > read_minibuf_noninteractive, which again is only called after checking > executing-kbd-macro. > > * src/keyboard.c (read_char): Add call to > barf_if_interaction_inhibited. (bug#67837) > * src/lread.c (Fread_char, Fread_event, Fread_char_exclusive): Remove > call to barf_if_interaction_inhibited. > * src/minibuf.c (Fread_from_minibuffer): Remove call to > barf_if_interaction_inhibited. > (read_minibuf_noninteractive): Add call to barf_if_interaction_inhibited. Please explain why you are removing the calls to barf_if_interaction_inhibited from many functions. It looks like they will now do some work instead of barfing right at the beginning. Why is that TRT? And I don't think I understand why we should care about a case when inhibit-interaction is non-nil, and Emacs needs to execute a keyboard macro, since executing keyboard macros is basically similar to interactive invocations of commands. What are the real-life use cases for that? > + } else This is against our style in C sources.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Spencer Baugh <sbaugh@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 19:49:03 +0000 Resent-Message-ID: <handler.67837.B67837.170266974020103 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii <eliz@HIDDEN> Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170266974020103 (code B ref 67837); Fri, 15 Dec 2023 19:49:03 +0000 Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 19:49:00 +0000 Received: from localhost ([127.0.0.1]:53494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEEBA-0005EA-6x for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 14:49:00 -0500 Received: from mxout2.mail.janestreet.com ([38.105.200.79]:56823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rEEB7-0005Dp-6O for 67837 <at> debbugs.gnu.org; Fri, 15 Dec 2023 14:48:58 -0500 From: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <83le9vnvnn.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 15 Dec 2023 20:54:52 +0200") References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> Date: Fri, 15 Dec 2023 14:48:51 -0500 Message-ID: <ier8r5vl00s.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: Lars Ingebrigtsen <larsi@HIDDEN> >> From: Spencer Baugh <sbaugh@HIDDEN> >> Date: Fri, 15 Dec 2023 11:50:29 -0500 >> >> >From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001 >> From: Spencer Baugh <sbaugh@HIDDEN> >> Date: Fri, 15 Dec 2023 11:39:24 -0500 >> Subject: [PATCH] Make inhibit-interaction work properly with keyboard macros >> >> Previously, inhibit-interaction=t prevented keyboard macros from >> running, even when those macros did not result in user interaction, >> since it was checked before the keyboard macro code had a chance to >> provide input. >> >> Now, if there's a running keyboard macro which can provide input, that >> keyboard macro is allowed to provide input even if >> inhibit-interaction=t. This is achieved by moving the check on >> inhibit-interaction to run after checking executing-kbd-macro in the >> low-level input handling mechanism, read_char. >> >> inhibit-interaction also suppresses reading from stdin in batch mode, >> so we also must add a check on inhibit-interaction to >> read_minibuf_noninteractive, which again is only called after checking >> executing-kbd-macro. >> >> * src/keyboard.c (read_char): Add call to >> barf_if_interaction_inhibited. (bug#67837) >> * src/lread.c (Fread_char, Fread_event, Fread_char_exclusive): Remove >> call to barf_if_interaction_inhibited. >> * src/minibuf.c (Fread_from_minibuffer): Remove call to >> barf_if_interaction_inhibited. >> (read_minibuf_noninteractive): Add call to barf_if_interaction_inhibited. > > Please explain why you are removing the calls to > barf_if_interaction_inhibited from many functions. It looks like they > will now do some work instead of barfing right at the beginning. Why > is that TRT? Those calls to barf_if_interaction_inhibited meant inhibit-interaction was checked before the keyboard macro code had a chance to provide input. I am moving the check on inhibit-interaction to run after checking executing-kbd-macro in the low-level input handling mechanism, read_char. This allows the keyboard macro is allowed to provide input even if inhibit-interaction=t. > > And I don't think I understand why we should care about a case when > inhibit-interaction is non-nil, and Emacs needs to execute a keyboard > macro, since executing keyboard macros is basically similar to > interactive invocations of commands. What are the real-life use cases > for that? Two concrete, real-life use cases: - Users write functions using keyboard macros and put them in hooks, which happen to get invoked by packages which use inhibit-interaction. Those functions don't actually require interaction, but because they break, ultimately no code can use inhibit-interaction. - I run tests in a batch Emacs, frequently using keyboard macros to provide input. Sometimes a bug causes code to run which calls read-char outside of a keyboard macro. I would like such read-char calls to error (instead of hanging, which is what they do by default in batch mode). If I bind inhibit-interaction=t, then read-char will exit with an error, but my keyboard macros will also immediately error. >> + } else > > This is against our style in C sources. Will fix in next patch.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Eli Zaretskii <eliz@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 20:02:02 +0000 Resent-Message-ID: <handler.67837.B67837.170267048131644 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh <sbaugh@HIDDEN> Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170267048131644 (code B ref 67837); Fri, 15 Dec 2023 20:02:02 +0000 Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 20:01:21 +0000 Received: from localhost ([127.0.0.1]:53502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEEN6-0008EJ-LA for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:01:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rEEN4-0008E0-8Q for 67837 <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:01:19 -0500 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 <eliz@HIDDEN>) id 1rEEMy-0002aU-AU; Fri, 15 Dec 2023 15:01:12 -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=IYtJMEqucD8wKIUgVVTBsgudY/5qrlsArOoz/Cv9Nyc=; b=DM4ZaLdMeN+m +L/vBkHy0Uq5Auvn1GIHHrJ55984GQlgfln0YnmC35PRQAcR86ostVpb2xXZRULHFWatZRUTek9e/ wZnkadf35B1Lz9eIOjj+latg3FmbiEkEG1rzDkuqzfhV+lR/KwGw99qB7zZuSnVgy9zlWCVdyNZwJ 1AW3YIGfoQPDF32nBKiKoyNUsaXZYCw4Joon5f73or4n4Nb5PXvaLYJ44D5iI9wPQGvIAz7ywQwJf hG9tq/K0mMpDhQSY/wfdBHzc36gDSrNCbYtFrAs7gXqLLXwHYZ6/jgq3faR9fUaJ2Tw6OtzaEAsAp 26gGdmhvQPDEvhp6hqE8/w==; Date: Fri, 15 Dec 2023 22:01:01 +0200 Message-Id: <83jzpfnsle.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> In-Reply-To: <ier8r5vl00s.fsf@HIDDEN> (message from Spencer Baugh on Fri, 15 Dec 2023 14:48:51 -0500) References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: Stefan Monnier <monnier@HIDDEN>, 67837 <at> debbugs.gnu.org, > larsi@HIDDEN > Date: Fri, 15 Dec 2023 14:48:51 -0500 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > Please explain why you are removing the calls to > > barf_if_interaction_inhibited from many functions. It looks like they > > will now do some work instead of barfing right at the beginning. Why > > is that TRT? > > Those calls to barf_if_interaction_inhibited meant inhibit-interaction > was checked before the keyboard macro code had a chance to provide > input. > > I am moving the check on inhibit-interaction to run after checking > executing-kbd-macro in the low-level input handling mechanism, > read_char. I'm saying that your proposal of fixing this will cause these functions to do some parts of their jobs before they realize that they can barf, and this will now happen even when they run not from a keyboard macro, and even if the keyboard macro doesn't actually provide any input. This is definitely not TRT. It affects use cases completely unrelated to the ones you wanted to fix, and affects them in adverse ways. > 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. > > And I don't think I understand why we should care about a case when > > inhibit-interaction is non-nil, and Emacs needs to execute a keyboard > > macro, since executing keyboard macros is basically similar to > > interactive invocations of commands. What are the real-life use cases > > for that? > > Two concrete, real-life use cases: > > - Users write functions using keyboard macros and put them in hooks, > which happen to get invoked by packages which use inhibit-interaction. > Those functions don't actually require interaction, but because they > break, ultimately no code can use inhibit-interaction. > > - I run tests in a batch Emacs, frequently using keyboard macros to > provide input. Sometimes a bug causes code to run which calls > read-char outside of a keyboard macro. I would like such read-char > calls to error (instead of hanging, which is what they do by default > in batch mode). If I bind inhibit-interaction=t, then read-char will > exit with an error, but my keyboard macros will also immediately > error. In both cases, using a function would solve the problem. So I'm not convinced we need to support those marginal cases, unless you can come up with a solution that will be both simple and will not affect unrelated use cases.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Spencer Baugh <sbaugh@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 20:11:02 +0000 Resent-Message-ID: <handler.67837.B67837.170267100832691 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii <eliz@HIDDEN> Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170267100832691 (code B ref 67837); Fri, 15 Dec 2023 20:11:02 +0000 Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 20:10:08 +0000 Received: from localhost ([127.0.0.1]:53512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEEVb-0008VC-Kw for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:10:08 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:55157) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rEEVZ-0008Ua-FU for 67837 <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:10:06 -0500 From: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <83jzpfnsle.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:01:01 +0200") References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> Date: Fri, 15 Dec 2023 15:09:59 -0500 Message-ID: <ier5y0zkz1k.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Cc: Stefan Monnier <monnier@HIDDEN>, 67837 <at> debbugs.gnu.org, >> larsi@HIDDEN >> Date: Fri, 15 Dec 2023 14:48:51 -0500 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> > Please explain why you are removing the calls to >> > barf_if_interaction_inhibited from many functions. It looks like they >> > will now do some work instead of barfing right at the beginning. Why >> > is that TRT? >> >> Those calls to barf_if_interaction_inhibited meant inhibit-interaction >> was checked before the keyboard macro code had a chance to provide >> input. >> >> I am moving the check on inhibit-interaction to run after checking >> executing-kbd-macro in the low-level input handling mechanism, >> read_char. > > I'm saying that your proposal of fixing this will cause these > functions to do some parts of their jobs before they realize that they > can barf, and this will now happen even when they run not from a > keyboard macro, and even if the keyboard macro doesn't actually > provide any input. This is definitely not TRT. It affects use cases > completely unrelated to the ones you wanted to fix, and affects them > in adverse ways. I think the effects on other use cases are only positive. If, for example, read-char would fail due to reasons other than inhibit-interaction, it will now fail for those reasons. Which is good, because it reduces the need for all code everywhere to think about the possibility that inhibit-interaction is non-nil. >> 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. How about if those original barf_if_interaction_inhibited calls only signal if executing-kbd-macro is nil? >> > And I don't think I understand why we should care about a case when >> > inhibit-interaction is non-nil, and Emacs needs to execute a keyboard >> > macro, since executing keyboard macros is basically similar to >> > interactive invocations of commands. What are the real-life use cases >> > for that? >> >> Two concrete, real-life use cases: >> >> - Users write functions using keyboard macros and put them in hooks, >> which happen to get invoked by packages which use inhibit-interaction. >> Those functions don't actually require interaction, but because they >> break, ultimately no code can use inhibit-interaction. >> >> - I run tests in a batch Emacs, frequently using keyboard macros to >> provide input. Sometimes a bug causes code to run which calls >> read-char outside of a keyboard macro. I would like such read-char >> calls to error (instead of hanging, which is what they do by default >> in batch mode). If I bind inhibit-interaction=t, then read-char will >> exit with an error, but my keyboard macros will also immediately >> error. > > In both cases, using a function would solve the problem. So I'm not > convinced we need to support those marginal cases, unless you can come > up with a solution that will be both simple and will not affect > unrelated use cases. - Are you suggesting that novice users should have to rewrite all their keyboard macros in Lisp? That sounds impractical. - How can I provide keyboard input to the interactive spec of a command I am testing, other than by using keyboard macros? I'd be pleased to have an alternative solution.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Eli Zaretskii <eliz@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 20:15:02 +0000 Resent-Message-ID: <handler.67837.B67837.1702671268739 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: sbaugh@HIDDEN Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.1702671268739 (code B ref 67837); Fri, 15 Dec 2023 20:15:02 +0000 Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 20:14:28 +0000 Received: from localhost ([127.0.0.1]:53522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEEZn-0000Bo-V0 for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:14:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rEEZn-0000Bd-1o for 67837 <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:14:27 -0500 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 <eliz@HIDDEN>) id 1rEEZg-0003EA-U2; Fri, 15 Dec 2023 15:14:20 -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=wCbJLfDBkDrGxcJi7f9IuHoaSwxP7VxbHqXSSfe7IN0=; b=rNp26mazRYKw 9t6a0k6W5QBv8MuPQeE5LliUHX19mNsnEp0gbZeW0dnth+aQGjVykkaWXv/zKVbn4b6gwIHvFSM8c ZoDd4sb/UASoJc75pLVJ4Zu/Tcp97pUWBx4ue10EEFlG4f8cte92lRksaIADzBdA5+zzJWpqQXmwC g5AiTkLTSOrKganXVhe7Sth7o1y9WJMeWmRw0+LewSgm6Z4o3gIEj+I9uE4UAtWHEiq6XdBuyoHI/ RXlLrvrpZnXaOiMp1EuQYDED+Bi3DAQIGHrl1t3wUQBwJGbfuvB//fguCDQDY8wGcA3z4jNzD4Z1V MgQ1IR/qPTjyiAl2tdWmqQ==; Date: Fri, 15 Dec 2023 22:14:11 +0200 Message-Id: <83h6kjnrzg.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> In-Reply-To: <83jzpfnsle.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 15 Dec 2023 22:01:01 +0200) References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN > Date: Fri, 15 Dec 2023 22:01:01 +0200 > From: Eli Zaretskii <eliz@HIDDEN> > > > 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.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Spencer Baugh <sbaugh@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 15 Dec 2023 20:40:01 +0000 Resent-Message-ID: <handler.67837.B67837.170267278023107 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii <eliz@HIDDEN> Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170267278023107 (code B ref 67837); Fri, 15 Dec 2023 20:40:01 +0000 Received: (at 67837) by debbugs.gnu.org; 15 Dec 2023 20:39:40 +0000 Received: from localhost ([127.0.0.1]:53606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEEyC-00060d-7c for submit <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:39:40 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:36247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rEEy9-00060O-Bi for 67837 <at> debbugs.gnu.org; Fri, 15 Dec 2023 15:39:38 -0500 From: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <83h6kjnrzg.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> Date: Fri, 15 Dec 2023 15:39:31 -0500 Message-ID: <ier34w3kxoc.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN >> Date: Fri, 15 Dec 2023 22:01:01 +0200 >> From: Eli Zaretskii <eliz@HIDDEN> >> >> > 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.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Eli Zaretskii <eliz@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 07:04:01 +0000 Resent-Message-ID: <handler.67837.B67837.170271018420866 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh <sbaugh@HIDDEN> Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170271018420866 (code B ref 67837); Sat, 16 Dec 2023 07:04:01 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 07:03:04 +0000 Received: from localhost ([127.0.0.1]:53851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEOhU-0005QT-0M for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 02:03:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rEOhR-0005Pz-Hz for 67837 <at> debbugs.gnu.org; Sat, 16 Dec 2023 02:03:03 -0500 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 <eliz@HIDDEN>) id 1rEOhL-0002u2-8B; Sat, 16 Dec 2023 02:02:55 -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=Zra1BIN/W54sJDsiwGKboJ+p7Lq9uySA9p0w5yoI7LM=; b=jLqxgXAO88Fv ADhn2fO1FFd73IhDLRnCDZTyOG5mvaXydb67caiPUQRFTPFht3V4VmuwsiEN6AZASBKHnLYsgT2+r 3Tt7f9oQuLY9DApvI7RrXE6/O58+e78fzlEy/UvMPdf31vOZsunEHNtsmsDY9XCf5C+Ta1yHbccHX z0Bi0rurCf0GTG2yYMGypy269X88nsN3TJ2DaUjk10MHL2ZWoyf+kT/e25sXWIv+EzvryX5CDyBtl o8071DUTUUtmDrYyQMz++pWSo3x/0iqrKfD+aXcStdvV0wQnCKDpoYQx4EBLVb5u4PRVoAKFf4H/f hlw8+YJwJVVl+EBDhzgINw==; Date: Sat, 16 Dec 2023 09:02:35 +0200 Message-Id: <83fs02ocj8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> In-Reply-To: <ier5y0zkz1k.fsf@HIDDEN> (message from Spencer Baugh on Fri, 15 Dec 2023 15:09:59 -0500) References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <ier5y0zkz1k.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN > Date: Fri, 15 Dec 2023 15:09:59 -0500 > > > I'm saying that your proposal of fixing this will cause these > > functions to do some parts of their jobs before they realize that they > > can barf, and this will now happen even when they run not from a > > keyboard macro, and even if the keyboard macro doesn't actually > > provide any input. This is definitely not TRT. It affects use cases > > completely unrelated to the ones you wanted to fix, and affects them > > in adverse ways. > > I think the effects on other use cases are only positive. If, for > example, read-char would fail due to reasons other than > inhibit-interaction, it will now fail for those reasons. Which is good, > because it reduces the need for all code everywhere to think about the > possibility that inhibit-interaction is non-nil. Most calls don't signal errors, so the part that is important is when they don'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. > > How about if those original barf_if_interaction_inhibited calls only > signal if executing-kbd-macro is nil? We could perhaps do that, but see my other message: I think it is fundamentally wrong to allow keyboard macros be exempt from this feature. > >> - Users write functions using keyboard macros and put them in hooks, > >> which happen to get invoked by packages which use inhibit-interaction. > >> Those functions don't actually require interaction, but because they > >> break, ultimately no code can use inhibit-interaction. > >> > >> - I run tests in a batch Emacs, frequently using keyboard macros to > >> provide input. Sometimes a bug causes code to run which calls > >> read-char outside of a keyboard macro. I would like such read-char > >> calls to error (instead of hanging, which is what they do by default > >> in batch mode). If I bind inhibit-interaction=t, then read-char will > >> exit with an error, but my keyboard macros will also immediately > >> error. > > > > In both cases, using a function would solve the problem. So I'm not > > convinced we need to support those marginal cases, unless you can come > > up with a solution that will be both simple and will not affect > > unrelated use cases. > > - Are you suggesting that novice users should have to rewrite all their > keyboard macros in Lisp? That sounds impractical. I don't see anything impractical here. > - How can I provide keyboard input to the interactive spec of a command > I am testing, other than by using keyboard macros? I'd be pleased to > have an alternative solution. Why do you need to do that when inhibit-interaction is non-nil in the first place? Code that needs interaction shouldn't be run or tested in those conditions.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Eli Zaretskii <eliz@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 07:16:01 +0000 Resent-Message-ID: <handler.67837.B67837.170271091825084 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh <sbaugh@HIDDEN> Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170271091825084 (code B ref 67837); Sat, 16 Dec 2023 07:16:01 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 07:15:18 +0000 Received: from localhost ([127.0.0.1]:53864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEOtJ-0006Vq-L8 for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 02:15:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rEOtH-00068q-BU for 67837 <at> debbugs.gnu.org; Sat, 16 Dec 2023 02:15:16 -0500 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 <eliz@HIDDEN>) id 1rEOtB-0000Gy-Cv; Sat, 16 Dec 2023 02:15:09 -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=YRS4J9YjTu0fQGZx4XU9ZHzJF+cey9HZ8lklGQ80BAY=; b=gfU1+1PxjrsD uOGyw42Uv70afM3RizgaO95Dwo8E6P0hv1z0OVkrtWqoZmRiR/6D8ciwSg1LWMuebW0nsQ5NnXCk4 4jmd+92OU05gfPgow1GiEQhONzrHAMa/8UmcszKt8TVBxGZR6kpOT+ZGW3BmYPvIBeDfG8H9rrdWP fWrFbrrZx+9LXNOuUB4mMry0eRGreKOQZgOf3Xls2y9oK2l5EbBqHs/FH323FfCqNr2KDnk888Lbn ZK3Qgk5E8jTiWpaS3JkqN0OLPnLQkpecvXXtMtGbQQWosiK2bLokhSx0KNZOM0W8CzZGGwH4Ub98n 3JS26t0b/xntKD9K5dRpWQ==; Date: Sat, 16 Dec 2023 09:14:47 +0200 Message-Id: <83edfmobyw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> In-Reply-To: <ier34w3kxoc.fsf@HIDDEN> (message from Spencer Baugh on Fri, 15 Dec 2023 15:39:31 -0500) References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> <ier34w3kxoc.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN > Date: Fri, 15 Dec 2023 15:39:31 -0500 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > > 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? Why would we want to do that? The inhibit-interaction variable was introduced for very special circumstances, and its purpose is clear: signal an error when any user interaction is requested. To introduce some kind of override of that behavior, in those situations where some Lisp program binds inhibit-interaction non-nil, would require serious justifications, since the easiest way of avoiding these problems is either not to bind inhibit-interaction non-nil in the first place, or provide a signal handler that will catch the error and DTRT. Emacs itself never sets this variable non-nil, it's entirely up to Lisp programs to use it. And Lisp programs that do bind it actually mean for interactions to signal an error, so making exceptions from that requires very good reasons. I don't think you presented such reasons; the use cases you described are frankly quite obscure, and can have other solutions. So I'm against complicating this feature that is currently very simple and understandable, and also not used widely enough for us to bother about such contrived circumstances, not enough for non-trivial internal changes anyway.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: sbaugh@HIDDEN Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 13:23:01 +0000 Resent-Message-ID: <handler.67837.B67837.170273295418531 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii <eliz@HIDDEN> Cc: Spencer Baugh <sbaugh@HIDDEN>, larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170273295418531 (code B ref 67837); Sat, 16 Dec 2023 13:23:01 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 13:22:34 +0000 Received: from localhost ([127.0.0.1]:54227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEUcj-0004op-UD for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 08:22:34 -0500 Received: from s.wfbtzhsw.outbound-mail.sendgrid.net ([159.183.224.105]:42786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bounces+21787432-0710-67837=debbugs.gnu.org@HIDDEN>) id 1rEUcg-0004oR-TJ for 67837 <at> debbugs.gnu.org; Sat, 16 Dec 2023 08:22:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=vyAbtETj3adOmb8oOk4vD3arLq34+sPoMFioaQSaans=; b=1OM1Noozrs713CLx7VQq/0JNF/pJaXJlFmZzOpKJCl/GbQpWRsEV6Zc0J0zJ18IstuuO LnxCECb8XXVoaq26uAIHf8/G4wEKiDDIN6uz8nVSpHnaBYDh5t4SgLjkMf1fNCBZn/WtI1 NEROYEjyL3IIBOJ6z2XrUGtnIYkP7Wi0h2svNJ1i1m6ocMj9KU1CqDOfT8vEo85G+S4tg8 +LLp20ZGFHBZtfILkOxarpwcScW4Cr9zRcm0drIexAM8kNGM5WBC0822Z8thlwihMyDYXD OTXZH36ZsnJ/iE27QCU+zu734S3XIOTMgAvcjmKCq7MgrCUdPwcUga9nJBSdMXGg== Received: by filterdrecv-655bd866f5-l7lp4 with SMTP id filterdrecv-655bd866f5-l7lp4-1-657DA48F-28 2023-12-16 13:22:23.719159449 +0000 UTC m=+418812.536721024 Received: from earth.catern.com (unknown) by geopod-ismtpd-35 (SG) with ESMTP id 6lduQ73kSFeMhGnBSE29vg Sat, 16 Dec 2023 13:22:23.656 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@HIDDEN; receiver=gnu.org Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id 2EE9763D12; Sat, 16 Dec 2023 08:20:40 -0500 (EST) From: sbaugh@HIDDEN In-Reply-To: <83fs02ocj8.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 16 Dec 2023 09:02:35 +0200") References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <ier5y0zkz1k.fsf@HIDDEN> <83fs02ocj8.fsf@HIDDEN> Date: Sat, 16 Dec 2023 13:22:23 +0000 (UTC) Message-ID: <87le9uthaw.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbKmRvMqrX2f6A+TogkmeObt6VIyNsJRh6zPAwAx5JLsgERE3VJTxoyTVc7LU/fzDqzVtUOUeMuwWc2vqFHx1O1Cy4oS+sncnQqdGwJqrGpBw2AxKECvN5dfLvgp7ImdmlFzVIf/0p0P477eJO5BvKnXH7qnlfzK4hnMjdIA4wyiZQ== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> >> - Users write functions using keyboard macros and put them in hooks, >> >> which happen to get invoked by packages which use inhibit-interaction. >> >> Those [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [159.183.224.105 listed in wl.mailspike.net] 1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL, https://senderscore.org/blocklistlookup/ [159.183.224.105 listed in bl.score.senderscore.com] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.0 T_SCC_BODY_TEXT_LINE No description available. X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.3 (/) Eli Zaretskii <eliz@HIDDEN> writes: >> >> - Users write functions using keyboard macros and put them in hooks, >> >> which happen to get invoked by packages which use inhibit-interaction. >> >> Those functions don't actually require interaction, but because they >> >> break, ultimately no code can use inhibit-interaction. >> >> >> >> - I run tests in a batch Emacs, frequently using keyboard macros to >> >> provide input. Sometimes a bug causes code to run which calls >> >> read-char outside of a keyboard macro. I would like such read-char >> >> calls to error (instead of hanging, which is what they do by default >> >> in batch mode). If I bind inhibit-interaction=t, then read-char will >> >> exit with an error, but my keyboard macros will also immediately >> >> error. >> > >> > In both cases, using a function would solve the problem. So I'm not >> > convinced we need to support those marginal cases, unless you can come >> > up with a solution that will be both simple and will not affect >> > unrelated use cases. >> >> - Are you suggesting that novice users should have to rewrite all their >> keyboard macros in Lisp? That sounds impractical. > > I don't see anything impractical here. Many users of Emacs are not programmers. They are able to use keyboard macros as a simple, non-programming way to make reusable functions and commands. Are you saying they should learn to program so that they can rewrite their keyboard macros by hand into Lisp? >> - How can I provide keyboard input to the interactive spec of a command >> I am testing, other than by using keyboard macros? I'd be pleased to >> have an alternative solution. > > Why do you need to do that when inhibit-interaction is non-nil in the > first place? Code that needs interaction shouldn't be run or tested > in those conditions. As I said before: because otherwise read-char outside a keyboard macro will hang, and I want my test to fail instead of hang in that case. Let me phrase the use case differently: I have some tests which I'd like to run in batch Emacs. By default, if any of the code under test runs read-char, Emacs will simply hang forever (that's what read-char does in batch mode). I would prefer instead that my tests to fail immediately if any code runs read-char. How would you suggest I do that? AFAIK the only way to achieve this currently is inhibit-interaction, although I'd be happy to add an alternative way to do that. So, to achieve this I'll use inhibit-interaction=t over my entire test suite. But then tests which make any use of a keyboard macro, for testing interactive specs for example, will fail!
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Eli Zaretskii <eliz@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 13:59:01 +0000 Resent-Message-ID: <handler.67837.B67837.170273508910496 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: sbaugh@HIDDEN Cc: sbaugh@HIDDEN, larsi@HIDDEN, 67837 <at> debbugs.gnu.org, monnier@HIDDEN Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170273508910496 (code B ref 67837); Sat, 16 Dec 2023 13:59:01 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 13:58:09 +0000 Received: from localhost ([127.0.0.1]:54263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEVBA-0002jE-N4 for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 08:58:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rEVB8-0002iq-L8 for 67837 <at> debbugs.gnu.org; Sat, 16 Dec 2023 08:58:07 -0500 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 <eliz@HIDDEN>) id 1rEVB2-0004XY-KW; Sat, 16 Dec 2023 08:58:00 -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=6aAfojqq3s8gbKIq+yej2y6Lnvrd0UbNsosipjU4AT8=; b=Mb6b76qPXKBd LSvI/2ADcdTJCPT5SWBabjb3KrazxHhr51tWVi8a8NNOiXmiFpEbpf1jIzZU3a+hHY6XeWicBukfn mgxZ9CcyueDnGCRNfN7yEU0N0OSwjyZyfgyn6zz9BIEtT/7xkNPYUaXmihGk0Jea4KNOiNwCqNHJQ W2zRYChGUMdRHMl8cHVqXukU77j8X6ZAFXZuLFas2di55GsXdlJg8tHLbpAvQ7M9JJNU6GaH5tnuJ 29cV6aYsAP/Zy/B1wwB7Q+2ycj0RSTI4h+o0M8663Q8eFh/4A7lfU/jzxKsGYOJOuWa2pSXccgzyt 2mYPCZjClTMNuHRayuekGw==; Date: Sat, 16 Dec 2023 15:57:42 +0200 Message-Id: <8334w2meqx.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> In-Reply-To: <87le9uthaw.fsf@HIDDEN> (sbaugh@HIDDEN) References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <ier5y0zkz1k.fsf@HIDDEN> <83fs02ocj8.fsf@HIDDEN> <87le9uthaw.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: sbaugh@HIDDEN > Date: Sat, 16 Dec 2023 13:22:23 +0000 (UTC) > Cc: Spencer Baugh <sbaugh@HIDDEN>, larsi@HIDDEN, > 67837 <at> debbugs.gnu.org, monnier@HIDDEN > > Eli Zaretskii <eliz@HIDDEN> writes: > > Why do you need to do that when inhibit-interaction is non-nil in the > > first place? Code that needs interaction shouldn't be run or tested > > in those conditions. > > As I said before: because otherwise read-char outside a keyboard macro > will hang, and I want my test to fail instead of hang in that case. The usual way of dealing with this in test frameworks is to mock read-char (or whatever function that causes trouble when running tests). As long as read-char is not the API you are testing, you don't really need read-char as it works in Emacs, you need something that will provide the same output. > Let me phrase the use case differently: > > I have some tests which I'd like to run in batch Emacs. By default, if > any of the code under test runs read-char, Emacs will simply hang > forever (that's what read-char does in batch mode). > > I would prefer instead that my tests to fail immediately if any code > runs read-char. How would you suggest I do that? Define a replacement read-char in the test harness that accepts the same arguments and signals an error.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Stefan Monnier <monnier@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 15:53:01 +0000 Resent-Message-ID: <handler.67837.B67837.17027419765339 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii <eliz@HIDDEN> Cc: sbaugh@HIDDEN, larsi@HIDDEN, control <at> debbugs.gnu.org, 67837 <at> debbugs.gnu.org Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.17027419765339 (code B ref 67837); Sat, 16 Dec 2023 15:53:01 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 15:52:56 +0000 Received: from localhost ([127.0.0.1]:55802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEWyG-0001O2-2X for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 10:52:56 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1rEWyD-0001Nl-KI; Sat, 16 Dec 2023 10:52:54 -0500 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== 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) 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) From: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <83h6kjnrzg.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") Message-ID: <jwvttoi2mcr.fsf-monnier+emacs@HIDDEN> References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sat, 16 Dec 2023 10:52:45 -0500 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.031 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) 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
Received: (at control) by debbugs.gnu.org; 16 Dec 2023 15:52:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 16 10:52:56 2023 Received: from localhost ([127.0.0.1]:55804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEWyG-0001O4-EG for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 10:52:56 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1rEWyD-0001Nl-KI; Sat, 16 Dec 2023 10:52:54 -0500 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== 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) 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) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83h6kjnrzg.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") Message-ID: <jwvttoi2mcr.fsf-monnier+emacs@HIDDEN> References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sat, 16 Dec 2023 10:52:45 -0500 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.031 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control Cc: sbaugh@HIDDEN, larsi@HIDDEN, control <at> debbugs.gnu.org, 67837 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) 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
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Stefan Monnier <monnier@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 15:54:02 +0000 Resent-Message-ID: <handler.67837.B67837.17027419915423 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii <eliz@HIDDEN> Cc: sbaugh@HIDDEN, larsi@HIDDEN, control <at> debbugs.gnu.org, 67837 <at> debbugs.gnu.org Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.17027419915423 (code B ref 67837); Sat, 16 Dec 2023 15:54:02 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 15:53:11 +0000 Received: from localhost ([127.0.0.1]:55811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEWyU-0001PO-Sb for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 10:53:11 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1rEWyT-0001P8-OV; Sat, 16 Dec 2023 10:53:10 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A70D8441D11; Sat, 16 Dec 2023 10:53:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702741982; bh=y3TunpwzOogYXMRijDfv+4WgoZgt6MZMom8n6ftW0I0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=exgUzDmNgCzsKFqDlgRmiZaLuckdBv8G4GcrfB9pOpiye21FbLVpILR3ZiEgaoYwi 7rd0oazbLqjv4WvrUJby4XdqreLJBnPSqr5es9BRRgRYOyJCBLsCa2cj5cjzsyBvN4 SXD4leoWxEYlGqVjVc7B63jbS8LsmE/K2IdFasZO/JDSAW3t5qLqFLZBv0787AVt4F wIyOMOPsG+UYHEJlCUbCMh66cJ+cyMJ9tMcLw4AX3dsbpg3J2KODFonOBGXUQdqY0v bfT9x/OOm0iRihFkJTRK+V+No9rQmDuhlmap3lfZSdFboI4h4qgdtubcNvOchR9WCj e5+S8lKeSvDiA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 23F06441D03; Sat, 16 Dec 2023 10:53:02 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E62A0120476; Sat, 16 Dec 2023 10:53:01 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <83h6kjnrzg.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") Message-ID: <jwvttoi2mcr.fsf-monnier+emacs@HIDDEN> References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sat, 16 Dec 2023 10:53:01 -0500 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.680 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DCC_CHECK 1.1 Detected as bulk mail by DCC (dcc-servers.net) DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain FSL_BULK_SIG 2.064 Bulk signature with no Unsubscribe T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) 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
Received: (at control) by debbugs.gnu.org; 16 Dec 2023 15:53:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 16 10:53:11 2023 Received: from localhost ([127.0.0.1]:55813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEWyV-0001PQ-6T for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 10:53:11 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1rEWyT-0001P8-OV; Sat, 16 Dec 2023 10:53:10 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A70D8441D11; Sat, 16 Dec 2023 10:53:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702741982; bh=y3TunpwzOogYXMRijDfv+4WgoZgt6MZMom8n6ftW0I0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=exgUzDmNgCzsKFqDlgRmiZaLuckdBv8G4GcrfB9pOpiye21FbLVpILR3ZiEgaoYwi 7rd0oazbLqjv4WvrUJby4XdqreLJBnPSqr5es9BRRgRYOyJCBLsCa2cj5cjzsyBvN4 SXD4leoWxEYlGqVjVc7B63jbS8LsmE/K2IdFasZO/JDSAW3t5qLqFLZBv0787AVt4F wIyOMOPsG+UYHEJlCUbCMh66cJ+cyMJ9tMcLw4AX3dsbpg3J2KODFonOBGXUQdqY0v bfT9x/OOm0iRihFkJTRK+V+No9rQmDuhlmap3lfZSdFboI4h4qgdtubcNvOchR9WCj e5+S8lKeSvDiA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 23F06441D03; Sat, 16 Dec 2023 10:53:02 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E62A0120476; Sat, 16 Dec 2023 10:53:01 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83h6kjnrzg.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") Message-ID: <jwvttoi2mcr.fsf-monnier+emacs@HIDDEN> References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sat, 16 Dec 2023 10:53:01 -0500 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.680 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DCC_CHECK 1.1 Detected as bulk mail by DCC (dcc-servers.net) DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain FSL_BULK_SIG 2.064 Bulk signature with no Unsubscribe T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control Cc: sbaugh@HIDDEN, larsi@HIDDEN, control <at> debbugs.gnu.org, 67837 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) 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
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Eli Zaretskii <eliz@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 16:10:02 +0000 Resent-Message-ID: <handler.67837.B67837.170274296717111 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier <monnier@HIDDEN> Cc: sbaugh@HIDDEN, larsi@HIDDEN, control <at> debbugs.gnu.org, 67837 <at> debbugs.gnu.org Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170274296717111 (code B ref 67837); Sat, 16 Dec 2023 16:10:02 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 16:09:27 +0000 Received: from localhost ([127.0.0.1]:55855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEXEF-0004Rp-3D for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 11:09:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rEXEC-0004RW-Gh; Sat, 16 Dec 2023 11:09:25 -0500 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 <eliz@HIDDEN>) 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==; Date: Sat, 16 Dec 2023 18:08:58 +0200 Message-Id: <83sf42ku3p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> In-Reply-To: <jwvttoi2mcr.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 16 Dec 2023 10:52:45 -0500) References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> <jwvttoi2mcr.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: sbaugh@HIDDEN, larsi@HIDDEN, 67837 <at> debbugs.gnu.org, > control <at> 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.
X-Loop: help-debbugs@HIDDEN Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Resent-From: Stefan Monnier <monnier@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 16 Dec 2023 17:19:02 +0000 Resent-Message-ID: <handler.67837.B67837.170274713811001 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 67837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii <eliz@HIDDEN> Cc: sbaugh@HIDDEN, larsi@HIDDEN, control <at> debbugs.gnu.org, 67837 <at> debbugs.gnu.org Received: via spool by 67837-submit <at> debbugs.gnu.org id=B67837.170274713811001 (code B ref 67837); Sat, 16 Dec 2023 17:19:02 +0000 Received: (at 67837) by debbugs.gnu.org; 16 Dec 2023 17:18:58 +0000 Received: from localhost ([127.0.0.1]:55881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rEYJV-0002rL-VH for submit <at> debbugs.gnu.org; Sat, 16 Dec 2023 12:18:58 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58287) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1rEYJU-0002qw-B0; Sat, 16 Dec 2023 12:18:57 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 41CAC80B9B; Sat, 16 Dec 2023 12:18:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702747129; bh=4tCQB6x5cG3oaxA/j31O6AKSHzdwf8gxhxOOO0SfmDc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VowZUT4zzkJdlby0TSWtj2v54/jvFggfGFbpKESI2WeX5FVk7r8eaKLpWntzMT9D7 FhCpZ5HQetE4Xyc5j6lH5OyVEdEPGkJxCTEoBbCx4Fy986rrlTKngsw7Yb1Dc8L9T3 9jkg47JjRd7hwQX3QaUf+ysaUR2nUTqRr301tkigfi28sZXnstYiIU3MsGZfysEJsy fh5dE5wELTLUsLpsHyxDm6/BB8oSSNdvKO8O9NEZrJthE8vu0nHSKYFOKCRPsg2TzF dipbV07SNsn6vyET0St+X6heDU7mVZuRB4v9a7AAVYXGn2S2/ulvVFJ8lo1EY8iAc6 DZH9h9wmZb7tg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1D80C80B02; Sat, 16 Dec 2023 12:18:49 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E032E120DC3; Sat, 16 Dec 2023 12:18:48 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <83sf42ku3p.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 16 Dec 2023 18:08:58 +0200") Message-ID: <jwvy1du137y.fsf-monnier+emacs@HIDDEN> References: <ieredfnl8dg.fsf@HIDDEN> <ierbkarl8a2.fsf@HIDDEN> <83le9vnvnn.fsf@HIDDEN> <ier8r5vl00s.fsf@HIDDEN> <83jzpfnsle.fsf@HIDDEN> <83h6kjnrzg.fsf@HIDDEN> <jwvttoi2mcr.fsf-monnier+emacs@HIDDEN> <83sf42ku3p.fsf@HIDDEN> Date: Sat, 16 Dec 2023 12:18:48 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.083 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> 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, That's fine. My goal is to bind it in `ert-run-tests-batch-and-exit` or as close to that as possible. >> 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. As mentioned, my motivation is to better handle tests that hang instead of failing. It's hard to know beforehand which ones of those tests will/may do that. Also, where could we let-bind `inhibit-interaction` such that it only affects those tests we decide need it? > 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. That's my opinion as well, and in my opinion `inhibit-interaction` is mostly meant for tests, so in my current local patch that tries to make it work for the whole test suite, I made that variable fairly lenient (it doesn't signal an error if you `read-event` with a timeout). Stefan
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.