From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 11:48:43 2023 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 ) id 1rEBMf-0002sB-Qh for submit@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 ) id 1rEBMc-0002rJ-Pl for submit@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 ) id 1rEBMX-0002ed-GE for bug-gnu-emacs@gnu.org; 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 ) id 1rEBMT-0003ke-7p for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 11:48:33 -0500 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: 29.1.90; inhibit-interaction breaks keyboard macros Date: Fri, 15 Dec 2023 11:48:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; 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-Debbugs-Envelope-To: submit Cc: Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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)) From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 11:50:37 2023 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 ) id 1rEBOW-0002wD-RU for submit@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 ) id 1rEBOV-0002vx-1Z for 67837@debbugs.gnu.org; Fri, 15 Dec 2023 11:50:35 -0500 From: Spencer Baugh To: 67837@debbugs.gnu.org Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: (Spencer Baugh's message of "Fri, 15 Dec 2023 11:48:27 -0500") References: Date: Fri, 15 Dec 2023 11:50:29 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67837 Cc: Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 13:55:10 2023 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 ) id 1rEDL3-0001WU-Lt for submit@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 ) id 1rEDL1-0001WD-4x for 67837@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 ) 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@gnu.org> From: Eli Zaretskii To: Spencer Baugh , Stefan Monnier In-Reply-To: (message from Spencer Baugh on Fri, 15 Dec 2023 11:50:29 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67837 Cc: 67837@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Lars Ingebrigtsen > From: Spencer Baugh > Date: Fri, 15 Dec 2023 11:50:29 -0500 > > >From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001 > From: Spencer Baugh > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 14:49:00 2023 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 ) id 1rEEBA-0005EA-6x for submit@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 ) id 1rEEB7-0005Dp-6O for 67837@debbugs.gnu.org; Fri, 15 Dec 2023 14:48:58 -0500 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83le9vnvnn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Dec 2023 20:54:52 +0200") References: <83le9vnvnn.fsf@gnu.org> Date: Fri, 15 Dec 2023 14:48:51 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Cc: Lars Ingebrigtsen >> From: Spencer Baugh >> Date: Fri, 15 Dec 2023 11:50:29 -0500 >> >> >From b0f680393991d9ccbd888be8f754a85775196799 Mon Sep 17 00:00:00 2001 >> From: Spencer Baugh >> 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 15:01:21 2023 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 ) id 1rEEN6-0008EJ-LA for submit@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 ) id 1rEEN4-0008E0-8Q for 67837@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 ) 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@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 15 Dec 2023 14:48:51 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Stefan Monnier , 67837@debbugs.gnu.org, > larsi@gnus.org > Date: Fri, 15 Dec 2023 14:48:51 -0500 > > Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 15:10:08 2023 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 ) id 1rEEVb-0008VC-Kw for submit@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 ) id 1rEEVZ-0008Ua-FU for 67837@debbugs.gnu.org; Fri, 15 Dec 2023 15:10:06 -0500 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83jzpfnsle.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:01:01 +0200") References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> Date: Fri, 15 Dec 2023 15:09:59 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: Stefan Monnier , 67837@debbugs.gnu.org, >> larsi@gnus.org >> Date: Fri, 15 Dec 2023 14:48:51 -0500 >> >> Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 15:14:28 2023 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 ) id 1rEEZn-0000Bo-V0 for submit@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 ) id 1rEEZn-0000Bd-1o for 67837@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 ) 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@gnu.org> From: Eli Zaretskii To: sbaugh@janestreet.com In-Reply-To: <83jzpfnsle.fsf@gnu.org> (message from Eli Zaretskii on Fri, 15 Dec 2023 22:01:01 +0200) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca > Date: Fri, 15 Dec 2023 22:01:01 +0200 > From: Eli Zaretskii > > > This allows the keyboard macro is allowed to provide input even if > > inhibit-interaction=t. > > Please find a way of fixing the case of a keyboard macro that provides > input without adversely affecting the other cases where these > functions are called with inhibit-interaction=t. I'm actually tend to think that this proposal is fundamentally wrong, not just problematic implementation-wise. Providing input from a keyboard macro is still input, and inhibit-interaction=t means asking for input signals an error. So your suggestion subverts this feature, and therefore it is simply wrong to install something like that. IOW, signaling an error in these cases is exactly TRT, and we should not let keyboard macros circumvent this mechanism. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 15 15:39:40 2023 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 ) id 1rEEyC-00060d-7c for submit@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 ) id 1rEEy9-00060O-Bi for 67837@debbugs.gnu.org; Fri, 15 Dec 2023 15:39:38 -0500 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83h6kjnrzg.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> Date: Fri, 15 Dec 2023 15:39:31 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Fri, 15 Dec 2023 22:01:01 +0200 >> From: Eli Zaretskii >> >> > This allows the keyboard macro is allowed to provide input even if >> > inhibit-interaction=t. >> >> Please find a way of fixing the case of a keyboard macro that provides >> input without adversely affecting the other cases where these >> functions are called with inhibit-interaction=t. > > I'm actually tend to think that this proposal is fundamentally wrong, > not just problematic implementation-wise. Providing input from a > keyboard macro is still input, and inhibit-interaction=t means asking > for input signals an error. So your suggestion subverts this feature, > and therefore it is simply wrong to install something like that. > > IOW, signaling an error in these cases is exactly TRT, and we should > not let keyboard macros circumvent this mechanism. If that's the case, then could we add another variable which does behave like I propose with these patches? That is, it allows input from keyboard macros, but not from the user? That is personally what I want in my packages, because it doesn't break users who use keyboard macros, and it supports my use case of making read-char error in batch mode. Or perhaps, another possible value of inhibit-interaction, which behaves like that? BTW, I'm curious to hear what Lars thinks, because I expect that "keyboard macros should not work within inhibit-interaction=t" was not at all part of the plan. Although, I guess with my change, a keyboard macro which calls a function which internally sets inhibit-interaction=t will effectively ignore the inhibit-interaction setting. Which is definitely not correct. The correct behavior is a bit subtle; also important to consider are kbd-macro-query and recursive-edit. Here are some nesting situations, and what I suggest read-char should do in each of them: kmacro: get kmacro input i-i=t: error i-i=t, then kmacro: get kmacro input kmacro, then i-i=t: error i-i=t, kmacro, i-i=t: error kmacro, i-i=t, kmacro: get inner kmacro input kmacro, recursive-edit: get user input i-i=t, recursive-edit: error i-i=t, kmacro, recursive-edit: error kmacro, i-i=t, recursive-edit: error So basically, i-i=t means any request for user input should fail, which my change achieves; but also, if i-i=t was bound *after* the kmacro, then any request for kmacro input should also fail. Not sure how to achieve that. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 02:03:04 2023 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 ) id 1rEOhU-0005QT-0M for submit@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 ) id 1rEOhR-0005Pz-Hz for 67837@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 ) 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@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 15 Dec 2023 15:09:59 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 02:15:18 2023 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 ) id 1rEOtJ-0006Vq-L8 for submit@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 ) id 1rEOtH-00068q-BU for 67837@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 ) 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@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 15 Dec 2023 15:39:31 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca > Date: Fri, 15 Dec 2023 15:39:31 -0500 > > Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 08:22:34 2023 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 ) id 1rEUcj-0004op-UD for submit@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 ) id 1rEUcg-0004oR-TJ for 67837@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@catern.com; 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@catern.com Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83fs02ocj8.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 Dec 2023 09:02:35 +0200") References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83fs02ocj8.fsf@gnu.org> Date: Sat, 16 Dec 2023 13:22:23 +0000 (UTC) Message-ID: <87le9uthaw.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbKmRvMqrX2f6A+TogkmeO?= =?us-ascii?Q?bt6VIyNsJRh6zPAwAx5JLsgERE3VJTxoyTVc7LU?= =?us-ascii?Q?=2FfzDqzVtUOUeMuwWc2vqFHx1O1Cy4oS+sncnQqd?= =?us-ascii?Q?GwJqrGpBw2AxKECvN5dfLvgp7ImdmlFzVIf=2F0p0?= =?us-ascii?Q?P477eJO5BvKnXH7qnlfzK4hnMjdIA4wyiZQ=3D=3D?= To: Eli Zaretskii 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 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-Debbugs-Envelope-To: 67837 Cc: Spencer Baugh , larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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! From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 08:58:09 2023 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 ) id 1rEVBA-0002jE-N4 for submit@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 ) id 1rEVB8-0002iq-L8 for 67837@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 ) 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@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87le9uthaw.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83fs02ocj8.fsf@gnu.org> <87le9uthaw.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Sat, 16 Dec 2023 13:22:23 +0000 (UTC) > Cc: Spencer Baugh , larsi@gnus.org, > 67837@debbugs.gnu.org, monnier@iro.umontreal.ca > > Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 10:52:56 2023 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 ) id 1rEWyG-0001O2-2X for submit@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 ) 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 To: Eli Zaretskii Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83h6kjnrzg.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200") Message-ID: References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> 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: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, control@debbugs.gnu.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 11:09:27 2023 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 ) id 1rEXEF-0004Rp-3D for submit@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 16 Dec 2023 10:52:45 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, control@debbugs.gnu.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org, > control@debbugs.gnu.org > Date: Sat, 16 Dec 2023 10:52:45 -0500 > > merge 67837 65291 > thanks > > AFAICT this is the same bug as bug#65291 and the suggested patch is similar. > > > I'm actually tend to think that this proposal is fundamentally wrong, > > not just problematic implementation-wise. Providing input from a > > keyboard macro is still input, and inhibit-interaction=t means asking > > for input signals an error. So your suggestion subverts this feature, > > and therefore it is simply wrong to install something like that. > > I guess it begs the question: what is the purpose of > `inhibit-interaction`? > > The way I see it, the purpose is to avoid Emacs waiting for user input > when we know there's no user, and thus signal an error if we ever get to > this point. I agree. And signaling an error could be useful for either aborting some code which shouldn't interact with the user, or for catching the error and doing something alternative to user interaction. In the latter case, disabling the error can actually break some code. > Basically, I think since our test suite runs just fine in batch, we > should be able to run it with inhibit-interaction=t as well (which > would fix annoying problems when some test fails and ends up waiting > for user input). In general, yes. But the test suite can also be run interactively, and sometimes the ability to do so is very important for investigating test failures. > Note that trying to make the whole test suite runs with > `inhibit-interaction` non-nil is not at all straightforward, sadly: > there are several places where we do call things like `read-event` > without providing any keyboard input (i.e. without > `unread-command-event` or keyboard macros) and instead use a timeout > because this `read-event` is just there to force Emacs to wait while > some external process sends us some reply. Should these be considered > "interaction"? If not, then we open up a whole where some code may call > `read-event` with a relatively short timeout within a tight loop where > the purpose *is* to get user input and where the timeout is only present > to keep something else updated while we wait for that user's input. I see no reason to insist that everything in the test suite _must_ be runnable with inhibit-interaction non-nil. The only purpose of the test suite is to test whatever each test is testing, there are no other requirements. The code could be not very clean; if it does the job, that is fine from where I stand. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 12:18:58 2023 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 ) id 1rEYJV-0002rL-VH for submit@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 ) 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 To: Eli Zaretskii Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <83sf42ku3p.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 Dec 2023 18:08:58 +0200") Message-ID: References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> <83sf42ku3p.fsf@gnu.org> 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-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, control@debbugs.gnu.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 16 17:27:18 2024 Received: (at 67837) by debbugs.gnu.org; 16 Feb 2024 22:27:18 +0000 Received: from localhost ([127.0.0.1]:60305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rb6fs-0003u6-6X for submit@debbugs.gnu.org; Fri, 16 Feb 2024 17:27:17 -0500 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:52197) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rb6fn-0003tk-4U for 67837@debbugs.gnu.org; Fri, 16 Feb 2024 17:27:15 -0500 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: (Stefan Monnier's message of "Sat, 16 Dec 2023 10:52:45 -0500") References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> Date: Fri, 16 Feb 2024 17:26:45 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1708122405; bh=uxuA6p8Unaecpc1t0AACGWldV5JESLH4xW9P8FAjv30=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=ndN79NH0oYTmf6/iu7jK7VYWYUiJSDTPgKWLv6fmPl+qOLzwXkq/IfFAIgeIWYAcr D2MvO8IT455HFRyfEGW1E2/47DCUEZugl2HmC24V9p8G5dRpD7CUvybrp4IDRKlVYQ ryRtH2UmUKoLY9Zyz7rABXTjzowcgps1USi80wlVde/G7VVcEFhtU92C1it8Z/AdRp 2EEfXZNGwzSiapdfBRMUGnENQJ5+K1FppucPCexA6oWkX8v9ryirYlD4zhg2ld0xOx 7lk+dpjCwS14VHecr0Ogk9VKbAxqfvzDPNDUgRtR88cO4nR7Bh3Hf+LuPFqQBXVcXa HL1a5e4RXuP/A== X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 67837 Cc: 67837@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) Stefan Monnier writes: > 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). Yes, I agree. I'm interested in making this possible and willing to put in the work to do it for the Emacs test suite. (since it will help make my own tests reliable) > 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. What places are these? I think that does sound like interaction to me. In which case, could we change those places to not use read-event? Those places would break anyway if they ran inside a user-defined keyboard macro, if I understand correctly, so it's useful to fix them. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 16 18:28:19 2024 Received: (at 67837) by debbugs.gnu.org; 16 Feb 2024 23:28:19 +0000 Received: from localhost ([127.0.0.1]:60319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rb7cw-00086y-EK for submit@debbugs.gnu.org; Fri, 16 Feb 2024 18:28:19 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4425) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rb7cs-00086W-Et for 67837@debbugs.gnu.org; Fri, 16 Feb 2024 18:28:17 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A34E88064F; Fri, 16 Feb 2024 18:27:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708126066; bh=+z9Btj/yedCilEm2fZZ7T+qtc4WX+TXEqGZQi7RGnjQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jiQxCIXb6mK0Z1A+n/XgNJuEru41Phsn05cAw9y7Tty1MAbQ47X23m9xta1kksaSk w39FL0wSxUdF0vyL9QDko9pWvN1bBmIuEzm7dNslEy+cs7vK9znEmW4g6SZAo2yEby tJtBAFdGamRHKi0GyqliNoY704fVGgqXMJyj+HZKkbAA2SJ6ZNITK532bIDhUT3PRF JrHNonDjimsSeiAy51OPaQn7eDoiszyLlGRQruIsDu0PlKZvV8j4TzjAQVug7jWux4 jzw5st2PRQmpHzz+6rmX3ZizMnUO7M5/kcJrMP1ow/snQwIyBH4wlpH5/Mm8+BGx8d Z9yde7jBuHGxQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A3F4080469; Fri, 16 Feb 2024 18:27:46 -0500 (EST) Received: from pastel (unknown [45.72.205.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6FBED120213; Fri, 16 Feb 2024 18:27:46 -0500 (EST) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: (Spencer Baugh's message of "Fri, 16 Feb 2024 17:26:45 -0500") Message-ID: References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> Date: Fri, 16 Feb 2024 18:27:44 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.069 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: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: 67837@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) --=-=-= Content-Type: text/plain >> 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). > > Yes, I agree. I'm interested in making this possible and willing to put > in the work to do it for the Emacs test suite. (since it will help make > my own tests reliable) IIUC, Eli is opposed to changing the behavior of `inhibit-interaction`, so I think this will require a new variable, whose purpose is similar but will allow more "quasi interactions" (most importantly calling `read-event` with a timeout). If you're interested, here's my WiP patch (which modifies the way `inhibit-interaction` behaves). The most delicate point might be the change to `sit-for` in batch mode: I don't have a clear idea why we use `sleep-for` there and what is the impact of using `read-event` instead. Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=inhibit-interaction.patch diff --git a/lisp/emacs-lisp/ert.el b/lisp/emacs-lisp/ert.el index 8ab57d2b238..1ce84a1a2a9 100644 --- a/lisp/emacs-lisp/ert.el +++ b/lisp/emacs-lisp/ert.el @@ -1522,7 +1522,9 @@ ert-run-tests-batch-and-exit (or noninteractive (user-error "This function is only for use in batch mode")) (let ((eln-dir (and (featurep 'native-compile) - (make-temp-file "test-nativecomp-cache-" t)))) + (make-temp-file "test-nativecomp-cache-" t))) + ;; Don't ever wait for user input. + (inhibit-interaction t)) (when eln-dir (startup-redirect-eln-cache eln-dir)) ;; Better crash loudly than attempting to recover from undefined diff --git a/lisp/subr.el b/lisp/subr.el index c317d558e24..aaeb8d0fb00 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -3570,9 +3570,6 @@ sit-for ;; Then it was moved here using an implementation based on an idle timer, ;; which was then replaced by the use of read-event. (cond - (noninteractive - (sleep-for seconds) - t) ((input-pending-p t) nil) ((or (<= seconds 0) diff --git a/src/keyboard.c b/src/keyboard.c index 4b5e20fb24c..5d29b1bfe8b 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -2815,7 +2819,10 @@ read_char (int commandflag, Lisp_Object map, situation where an idle timer calls `sit-for'. */ if (!end_time) - timer_start_idle (); + { + barf_if_interaction_inhibited (); + timer_start_idle (); + } /* If in middle of key sequence and minibuffer not active, start echoing if enough time elapses. */ @@ -2875,8 +2882,12 @@ read_char (int commandflag, Lisp_Object map, because the recursive call of read_char in read_char_minibuf_menu_prompt does not pass on any keymaps. */ + /* FIXME: If the keymap is *not* a menu, this fails miserably, + signaling (error "Empty menu") instead! */ if (KEYMAPP (map) && INTERACTIVE && !NILP (prev_event) + /* FIXME: These conditions are re-tested redundantly inside + read_char_x_menu_prompt! */ && EVENT_HAS_PARAMETERS (prev_event) && !EQ (XCAR (prev_event), Qmenu_bar) && !EQ (XCAR (prev_event), Qtab_bar) @@ -2884,7 +2895,11 @@ read_char (int commandflag, Lisp_Object map, /* Don't bring up a menu if we already have another event. */ && !CONSP (Vunread_command_events)) { + barf_if_interaction_inhibited (); c = read_char_x_menu_prompt (map, prev_event, used_mouse_menu); + /* FIXME: read_char_x_menu_prompt can sometimes do nothing and just + return nil, should we really stop the idle timer and jump to `exit` + in that case? */ /* Now that we have read an event, Emacs is not idle. */ if (!end_time) @@ -9872,17 +9872,13 @@ if (! menu_prompting) return Qnil; - /* If we got to this point via a mouse click, - use a real menu for mouse selection. */ - if (EVENT_HAS_PARAMETERS (prev_event) + eassert (EVENT_HAS_PARAMETERS (prev_event) && !EQ (XCAR (prev_event), Qmenu_bar) && !EQ (XCAR (prev_event), Qtab_bar) - && !EQ (XCAR (prev_event), Qtool_bar)) - { - /* Display the menu and get the selection. */ - Lisp_Object value; + && !EQ (XCAR (prev_event), Qtool_bar)); - value = x_popup_menu_1 (prev_event, get_keymap (map, 0, 1)); + /* Display the menu and get the selection. */ + Lisp_Object value = x_popup_menu_1 (prev_event, get_keymap (map, 0, 1)); if (CONSP (value)) { Lisp_Object tem; @@ -9917,8 +9917,6 @@ if (used_mouse_menu) *used_mouse_menu = true; return value; - } - return Qnil ; } static Lisp_Object @@ -13116,6 +13125,15 @@ syms_of_keyboard (void) defsubr (&Sposn_at_point); defsubr (&Sposn_at_x_y); + defsubr (&Sadjust_point_for_property); + DEFVAR_LISP ("point-adjustment-function", + Vpoint_adjustment_function, + doc: /* Function called to adjust point after commands. +This function is run after each command that moved point, +unless `disable-point-adjustment' or `global-disable-point-adjustment' +is non-nil. */); + Vpoint_adjustment_function = intern ("adjust-point-for-property"); + DEFVAR_LISP ("last-command-event", last_command_event, doc: /* Last input event of a key sequence that called a command. See Info node `(elisp)Command Loop Info'.*/); diff --git a/src/lread.c b/src/lread.c index c11c641440d..aa301980904 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 (); @@ -5157,7 +5151,7 @@ DEFUN ("unintern", Funintern, Sunintern, 1, 2, 0, return Qt; } -/* Return the symbol in OBARRAY whose names matches the string +/* Return the symbol in OBARRAY whose name matches the string of SIZE characters (SIZE_BYTE bytes) at PTR. If there is no such symbol, return the integer bucket number of where the symbol would be if it were present. diff --git a/src/minibuf.c b/src/minibuf.c index 7c0c9799a60..1cb91ec2636 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -316,6 +316,8 @@ read_minibuf_noninteractive (Lisp_Object prompt, bool expflag, struct emacs_tty etty; bool etty_valid UNINIT; + barf_if_interaction_inhibited (); + /* Check, whether we need to suppress echoing. */ if (CHARACTERP (Vread_hide_char)) hide_char = XFIXNAT (Vread_hide_char); @@ -1344,8 +1346,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; diff --git a/test/lisp/autorevert-tests.el b/test/lisp/autorevert-tests.el index c202970e0b2..58002d597f0 100644 --- a/test/lisp/autorevert-tests.el +++ b/test/lisp/autorevert-tests.el @@ -110,7 +110,7 @@ auto-revert--wait-for-revert (if (and (or file-notify--library (file-remote-p temporary-file-directory)) (with-current-buffer buffer auto-revert-use-notify)) - (read-event nil nil 0.05) + (sit-for 0.05) (sleep-for 0.05))))) (defmacro auto-revert--deftest-remote (test docstring) @@ -429,7 +429,7 @@ auto-revert-test--wait-for (let ((ct (current-time))) (while (and (< (float-time (time-subtract nil ct)) max-wait) (not (funcall pred))) - (read-event nil nil 0.1)))) + (sit-for 0.1)))) (defun auto-revert-test--wait-for-buffer-text (buffer string max-wait) "Wait until BUFFER has the contents STRING, or MAX-WAIT seconds elapsed." diff --git a/test/lisp/filenotify-tests.el b/test/lisp/filenotify-tests.el index 28f4d5fa181..75d43a5c75d 100644 --- a/test/lisp/filenotify-tests.el +++ b/test/lisp/filenotify-tests.el @@ -77,8 +77,7 @@ file-notify--test-monitors (defun file-notify--test-wait-event () "Wait for one event. There are different timeouts for local and remote file notification libraries." - (read-event - nil nil + (sit-for (cond ;; gio/gpollfilemonitor.c declares POLL_TIME_SECS 5. So we must ;; wait at least this time in the GPollFileMonitor case. A diff --git a/test/lisp/net/dbus-tests.el b/test/lisp/net/dbus-tests.el index fec252e12dd..dd8200b345e 100644 --- a/test/lisp/net/dbus-tests.el +++ b/test/lisp/net/dbus-tests.el @@ -758,7 +758,7 @@ dbus-test05-register-signal dbus--test-interface member "foo") (with-timeout (1 (dbus--test-timeout-handler)) (while (null dbus--test-signal-received) - (read-event nil nil 0.1))) + (sit-for 0.1))) (should (equal dbus--test-signal-received '("foo"))) ;; Send two arguments, compound types. @@ -769,7 +769,7 @@ dbus-test05-register-signal '(:array :byte 1 :byte 2 :byte 3) '(:variant :string "bar")) (with-timeout (1 (dbus--test-timeout-handler)) (while (null dbus--test-signal-received) - (read-event nil nil 0.1))) + (sit-for 0.1))) (should (equal dbus--test-signal-received '((1 2 3) ("bar")))) ;; Unregister signal. @@ -1124,7 +1124,7 @@ dbus-test06-register-property-emits-signal (,dbus--test-service ,dbus--test-path)))) (with-timeout (1 (dbus--test-timeout-handler)) (while (null dbus--test-signal-received) - (read-event nil nil 0.1))) + (sit-for 0.1))) ;; It returns three arguments, "interface" (a string), ;; "changed_properties" (an array of dict entries) and ;; "invalidated_properties" (an array of strings). @@ -1150,7 +1150,7 @@ dbus-test06-register-property-emits-signal '(1 2 3))) (with-timeout (1 (dbus--test-timeout-handler)) (while (null dbus--test-signal-received) - (read-event nil nil 0.1))) + (sit-for 0.1))) (should (equal dbus--test-signal-received @@ -1883,7 +1883,7 @@ dbus-test08-register-monitor dbus--test-interface "Foo" "foo") (with-timeout (1 (dbus--test-timeout-handler)) (while (null dbus--test-signal-received) - (read-event nil nil 0.1))) + (sit-for 0.1))) ;; Unregister monitor. (should (dbus-unregister-object registered)) @@ -1896,7 +1896,7 @@ dbus-test08-register-monitor dbus--test-interface "Foo" "foo") (with-timeout (1 (ignore)) (while (null dbus--test-signal-received) - (read-event nil nil 0.1))) + (sit-for 0.1))) (should-not dbus--test-signal-received)) ;; Cleanup. diff --git a/test/lisp/progmodes/eglot-tests.el b/test/lisp/progmodes/eglot-tests.el index 4725885038e..d05851c8f4c 100644 --- a/test/lisp/progmodes/eglot-tests.el +++ b/test/lisp/progmodes/eglot-tests.el @@ -260,7 +260,7 @@ eglot--wait-for ;; `read-event' is essential to have the file ;; watchers come through. (cond ((fboundp 'flush-standard-output) - (read-event nil nil 0.1) (princ ".") + (sit-for 0.1) (princ ".") (flush-standard-output)) (t (read-event "." nil 0.1))) diff --git a/test/lisp/progmodes/flymake-tests.el b/test/lisp/progmodes/flymake-tests.el index 21dbb0711d2..043efcbd33c 100644 --- a/test/lisp/progmodes/flymake-tests.el +++ b/test/lisp/progmodes/flymake-tests.el @@ -47,12 +47,12 @@ flymake-tests--wait-for-backends ;; that will indeed unblock pending process output is ;; reading an input event, so, as a workaround, use a dummy ;; `read-event' with a very short timeout. - (unless noninteractive (read-event "" nil 0.1)) + (unless noninteractive (sit-for 0.1)) (cl-loop repeat 5 for notdone = (cl-set-difference (flymake-running-backends) (flymake-reporting-backends)) while notdone - unless noninteractive do (read-event "" nil 0.1) + unless noninteractive do (sit-for 0.1) do (sleep-for (+ 0.5 (or flymake-no-changes-timeout 0))) finally (when notdone (ert-skip (format "Some backends not reporting yet %s" diff --git a/test/src/inotify-tests.el b/test/src/inotify-tests.el index 0c078627786..9c2c957c049 100644 --- a/test/src/inotify-tests.el +++ b/test/src/inotify-tests.el @@ -61,7 +61,7 @@ inotify-file-watch-simple (progn (with-temp-file temp-file (insert "Foo\n")) - (read-event nil nil 5) + (sit-for 5) (should (> events 0))) (should (inotify-valid-p wd)) (inotify-rm-watch wd) diff --git a/test/src/thread-tests.el b/test/src/thread-tests.el index d9048dcf287..b41a89c834a 100644 --- a/test/src/thread-tests.el +++ b/test/src/thread-tests.el @@ -328,13 +328,13 @@ threads-signal-main-thread ;; We cannot use `ert-with-message-capture', because threads do not ;; know let-bound variables. (with-current-buffer "*Messages*" - (let (buffer-read-only) + (let ((inhibit-read-only t)) (erase-buffer)) (let ((thread (make-thread (lambda () (thread-signal main-thread 'error nil))))) (while (thread-live-p thread) (thread-yield)) - (read-event nil nil 0.1) + (sit-for 0.1) ;; No error has been raised, which is part of the test. (should (string-match --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 02:37:41 2024 Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 07:37:41 +0000 Received: from localhost ([127.0.0.1]:60366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFGW-0004D0-Ul for submit@debbugs.gnu.org; Sat, 17 Feb 2024 02:37:41 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56530) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFGT-0004Cm-CO for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 02:37:38 -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 ) id 1rbFG3-0007cZ-Ry; Sat, 17 Feb 2024 02:37:11 -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=euv5U5pn7hiP4D22CeOyUvYNCe2x2M4LY7W3ruXzxXE=; b=jFb4hx1LWvQY T6PFzqa8aXhAG3bseCHYpC4GEWMjM+hTU+AqRnqmVt4y9oDFmo7oioZrgowK2L+XB7QZNxWKmmYME zdKwpyPvx8mJwj2gC12GC0YvPsOJof5joTFFMIZz77dsAGcBgs+PITjM4yCE5G8ML+ntK1E/7Tf0P x37m3qnGHdC19GMNgfp8gYHlrVlV/PTdZDvgAvphkgw6oarxI3z2YGuZNJ6dU3o4SYylXzZckJeJg RMAZuNBSBkAFCSgERmUtLKZR2R0tBpaYen6bzSyCZuzueZtBU9nfu4pAIDLZl4J7cbvR/pa0B+V6R 3uU7ujPfvli/b0JBR6t1dQ==; Date: Sat, 17 Feb 2024 09:37:08 +0200 Message-Id: <86h6i7v8wr.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 16 Feb 2024 17:26:45 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: 67837@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > From: Spencer Baugh > Cc: Eli Zaretskii , larsi@gnus.org, 67837@debbugs.gnu.org > Date: Fri, 16 Feb 2024 17:26:45 -0500 > > Stefan Monnier writes: > > > merge 67837 65291 > > thanks > > > > AFAICT this is the same bug as bug#65291 and the suggested patch is similar. Alas, bug#65291 doesn't have any justification for the change, so I agree that they should be merged, but doing so doesn't add any useful information to this discussion, IMO. > >> 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). > > Yes, I agree. I'm interested in making this possible and willing to put > in the work to do it for the Emacs test suite. (since it will help make > my own tests reliable) And I'm still concerned that making these changes will be an incompatible change, because the functions that signaled the error right at the beginning will now do part of their job before signaling, and that could affect the net result of calling them in those cases. > > 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. > > What places are these? > > I think that does sound like interaction to me. In which case, could we > change those places to not use read-event? Those places would break > anyway if they ran inside a user-defined keyboard macro, if I understand > correctly, so it's useful to fix them. Btw, I think calling read-event with a timeout should not signal an error when interaction-inhibited is non-nil. But more generally, the above issues with our test suite are examples of non-trivial code which could be affected by the proposed changes. The justifications for these changes that were presented until now, such as they are, are very weak, and I therefore still object to making them, because the use cases where those changes are supposed to be useful can be taken care of by other means, like API mocking. >From where I stand, this is another example of taking marginal obscure use cases and promoting them to the level of a general problem that needs significant low-level changes whose effect is backward-incompatible behavior changes. Instead, those use cases should be handled with other techniques already available in Emacs that don't require any changes to our infrastructure. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 02:54:05 2024 Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 07:54:05 +0000 Received: from localhost ([127.0.0.1]:60376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFWP-0004gY-8W for submit@debbugs.gnu.org; Sat, 17 Feb 2024 02:54:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFWN-0004g3-77 for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 02:54:04 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rbFVx-0001wZ-2t; Sat, 17 Feb 2024 02:53:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4jolFUWWJGhKMc6x+nX5kVlH1gWCJbHYPFLr2AYUYwc=; b=Xc94PkfI6oaj 6+EywdwqHFQa95M3w9LjqL5G9dbd8mJvOqWAJoTYGkO77j3m3n0CIRmSeRLVEEMxs3Pwu1owfyfdz Co+0bzG2IoOGpwS2ujU5SS9/gvx8Dxl+iwH/SuZ/qwEe1uf/B/zWWIrW3B+G9WDZYjt8GlxKdkvFx fLqOcDiLHtY4qLfTL9j2EQRSQ7zQ7LFF1qa7UMWH5Htd573D5dsCRDsaxkX4Yyt5ZiWQCLu3Mmyh7 5rs0iZThFuDFpTptwvm0C0fmVkry8eiQgjsdH3fkl9wGQVDcSR3lMGKm70FXOizT6QiFs//itEh6d S2M6Hz3pElu4vmhw6xIOPg==; Date: Sat, 17 Feb 2024 09:53:33 +0200 Message-Id: <86frxrv85e.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 16 Feb 2024 18:27:44 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > From: Stefan Monnier > Cc: Eli Zaretskii , larsi@gnus.org, 67837@debbugs.gnu.org > Date: Fri, 16 Feb 2024 18:27:44 -0500 > > IIUC, Eli is opposed to changing the behavior of `inhibit-interaction`, I'm mostly opposed to making this kind of changes for reasons that are very weak, and basically are based on a special use case Spencer bumped into in his practice, a use case that can be resolved in a different way without any changes. I'm talking about Spencer's code which uses keyboard macros for mocking user input. I've seen no other justification for these behavior changes. > If you're interested, here's my WiP patch (which modifies the way > `inhibit-interaction` behaves). > > The most delicate point might be the change to `sit-for` in batch mode: > I don't have a clear idea why we use `sleep-for` there and what is the > impact of using `read-event` instead. Frankly, I don't understand the underlying ideas here. And it seems to include unrelated change(s)? E.g., what is this about: > + defsubr (&Sadjust_point_for_property); > + DEFVAR_LISP ("point-adjustment-function", > + Vpoint_adjustment_function, > + doc: /* Function called to adjust point after commands. > +This function is run after each command that moved point, > +unless `disable-point-adjustment' or `global-disable-point-adjustment' > +is non-nil. */); > + Vpoint_adjustment_function = intern ("adjust-point-for-property"); ? > diff --git a/test/lisp/autorevert-tests.el b/test/lisp/autorevert-tests.el > index c202970e0b2..58002d597f0 100644 > --- a/test/lisp/autorevert-tests.el > +++ b/test/lisp/autorevert-tests.el > @@ -110,7 +110,7 @@ auto-revert--wait-for-revert > (if (and (or file-notify--library > (file-remote-p temporary-file-directory)) > (with-current-buffer buffer auto-revert-use-notify)) > - (read-event nil nil 0.05) > + (sit-for 0.05) > (sleep-for 0.05))))) So we are supposed to replace all calls to read-event in our test suite with sit-for, and to be able to do that, we are now changing how sit-for behaves in non-interactive sessions? That sounds like a very serious incompatible change in behavior for a very weak reason -- the possibility to run the test suite with inhibit-interaction non-nil. I sincerely hope we will not make such changes for such reasons. If we do, we shouldn't be surprised that Emacs' stability does not improve with newer releases. With all due respect to our test suite, let's not forget that its main purpose is to allow us to test the various Emacs features. How we do that and whether we do it cleanly or not is completely unimportant, as long as the features get tested and tested well. It follows that the needs of the test suite should generally not require any infrastructure changes in Emacs; instead, we should jump through as many hoops as needed to test Emacs as it is. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 09:13:48 2024 Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 14:13:48 +0000 Received: from localhost ([127.0.0.1]:60565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbLRr-00017A-NG for submit@debbugs.gnu.org; Sat, 17 Feb 2024 09:13:48 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbLRp-00016x-0T for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 09:13:45 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CF3A9441D61; Sat, 17 Feb 2024 09:13:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708179196; bh=g6zDLrcSRZzpCamCGY5S6em6S6hQFeFn4QV+5+6oeg4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GTt2/GFGyRSmjv+ZkWbcFb5heJ6fPCBcR8u/0Z+uBGq8qr2Fu22JBtJxUdB+JdvTX xtKf3dnLUCMeqH1fcqgBqkqXUs8Okd/6Kln1avlKyLS/yFf3L2DKqXLsmcc+c81X7g UWH8A7Lh6IE+Q75m7wU1IZpHIMgQt9JDo0v0sI4+DBP5rUUuVcvfUUln+qEjLKeq+c ccKJCRec5Ju6robQk//rCDwpyleNO0uhsoB0K3Qttcap9ocodQWs6hs5qaQbWU2yr/ +X2LnSNf+ok1pMbsUP2eBrXZ0lppEDzsj1jhXeqMS68kTHoqn6ybCOy5ZJThGe/UMX rjxMn6XHCPTYw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BD3C1441D32; Sat, 17 Feb 2024 09:13:16 -0500 (EST) Received: from pastel (unknown [45.72.205.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 92F1312016C; Sat, 17 Feb 2024 09:13:16 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <86frxrv85e.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Feb 2024 09:53:33 +0200") Message-ID: References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> <86frxrv85e.fsf@gnu.org> Date: Sat, 17 Feb 2024 09:13:07 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.005 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: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > I'm mostly opposed to making this kind of changes for reasons that are > very weak, and basically are based on a special use case Spencer > bumped into in his practice, a use case that can be resolved in a > different way without any changes. I can't remember what Spencer's use case was, but for me the use case was simply that I was getting tired of having to kill Emacs processes that were hanging waiting for input while running the test suite. The specific reason why Emacs was waiting for input varied, it was usually linked to some bug I had introduced. AFAIK, `inhibit-interaction` is meant for those kinds of circumstances, but currently it can't be used for that because it basically rules out tests that have to wait for some async operation. You say: And I'm still concerned that making these changes will be an incompatible change, because the functions that signaled the error right at the beginning will now do part of their job before signaling, and that could affect the net result of calling them in those cases. Why are you concerned? Which code do you think will break? More specifically, have you ever seen or heard about a piece of code using `inhibit-interaction`? I have not, *except* in the context of bugs like this one. IOW, AFAICT, `inhibit-interaction` fails at providing the only feature for which it's useful. > And it seems to include unrelated change(s)? E.g., what is this > about: > >> + defsubr (&Sadjust_point_for_property); >> + DEFVAR_LISP ("point-adjustment-function", >> + Vpoint_adjustment_function, >> + doc: /* Function called to adjust point after commands. >> +This function is run after each command that moved point, >> +unless `disable-point-adjustment' or `global-disable-point-adjustment' >> +is non-nil. */); >> + Vpoint_adjustment_function =3D intern ("adjust-point-for-property"); > > ? My changes are WiP in my big-hunk-of-unrelated changes. So yes, I failed to excise every bit of the unrelated changes. [ FWIW, the above change is one I couldn't remember I had in my tree, and while I vaguely remember making it, I can't remember what it was for. =F0=9F=99=82 ] They're meant for Spencer or whoever else wants to work on this. They're definitely not meant to be anywhere near ready for inclusion. I can't even remember if I had convinced myself that this was the right way to go about it. Its main quality is that it pretty much works, so it's a useful starting point. >> diff --git a/test/lisp/autorevert-tests.el b/test/lisp/autorevert-tests.= el >> index c202970e0b2..58002d597f0 100644 >> --- a/test/lisp/autorevert-tests.el >> +++ b/test/lisp/autorevert-tests.el >> @@ -110,7 +110,7 @@ auto-revert--wait-for-revert >> (if (and (or file-notify--library >> (file-remote-p temporary-file-directory)) >> (with-current-buffer buffer auto-revert-use-notify)) >> - (read-event nil nil 0.05) >> + (sit-for 0.05) >> (sleep-for 0.05))))) > > So we are supposed to replace all calls to read-event in our test > suite with sit-for, and to be able to do that, we are now changing how > sit-for behaves in non-interactive sessions? Can't remember why I did it this way, TBH. Apparently using `read-event` was a problem I bumped into along the way. I probably made or kept that change thinking it's better anyway because it more clearly reflects the intention. > That sounds like a very serious incompatible change in behavior for > a very weak reason -- the possibility to run the test suite with > inhibit-interaction non-nil. IIUC you're talking about the `sit-for` change to not use `sleep-for`? Yes, it's an incompatible change. I think I made it thinking that it's probably a good idea anyway. We have a kind of a mess when it comes to waiting for external events: if you look at various pieces of code that have to do such waits, you'll tend to see that they all do it a bit differently, and if you look at the surrounding comments and Git history, you'll tend to see that it's the result of frustrating trial-and-failure bumping into various corner cases. The fact that `sit-for` currently allows async processes in interactive mode but not in batch mode is probably one of the sources of such problems. > I sincerely hope we will not make such changes for such reasons. We'll cross that bridge when we get there. Right now, I just sent Spencer a patch that kinds of summarizes what I've learned when I looked at that problem. If/when Spencer comes back with a patch he thinks is appropriate for `master` and it includes such changes, we'll discuss it then. > With all due respect to our test suite, let's not forget that its main > purpose is to allow us to test the various Emacs features. That doesn't mean that problems encountered while writing the test suite (e.g. the fact that `sit-for` doesn't read from async processes when used in batch) can't reflect real problems that also affect real code and thus deserve changes in Emacs proper. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 09:36:15 2024 Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 14:36:15 +0000 Received: from localhost ([127.0.0.1]:60572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbLna-0001b7-Vu for submit@debbugs.gnu.org; Sat, 17 Feb 2024 09:36:15 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbLnY-0001at-8U for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 09:36:13 -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 ) id 1rbLn8-0002ay-II; Sat, 17 Feb 2024 09:35:46 -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=aJCliFemsXOCDqQ8AvL2Ymjuc5Mv56fAHzxsIS613m4=; b=hhkBBOFUXba/ mzaR0Cqn4nOZTItdzpONiyE0c/K9bC+b11RPCtEaA9lHVBwKnozqAPXHvl4syfim9sz7uuOq/luFf Q4uSdmKa6Z1+SuzrUkAahGIaTJ3cPSpAMeudLHWtXmy75k+87sb41YP66jVjBgLQHkQ0BBhuu2zoX eCy+35nd00EMDTOiON3OAo5e8tEk0KoOu3GkLBMZ4M2w++H+X/Ajm1gLdwZHGG9idjzxVYOAYH0Mh TK2+4wY/XUnt8t3CPTO5KuCB0IDLGuAA49LnFUYIo8z0wHb4RTbtJCV6WRPDDc6aBsrut3XHXZ5jv n5RTqTSp/pJoH2g2+3JenA==; Date: Sat, 17 Feb 2024 16:35:42 +0200 Message-Id: <86r0hbtayp.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 17 Feb 2024 09:13:07 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> <86frxrv85e.fsf@gnu.org> X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > From: Stefan Monnier > Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org > Date: Sat, 17 Feb 2024 09:13:07 -0500 > > > I'm mostly opposed to making this kind of changes for reasons that are > > very weak, and basically are based on a special use case Spencer > > bumped into in his practice, a use case that can be resolved in a > > different way without any changes. > > I can't remember what Spencer's use case was, but for me the use case > was simply that I was getting tired of having to kill Emacs processes > that were hanging waiting for input while running the test suite. ?? I bump into this from time to time, but a simple Ctrl-C usually solves the problem on the spot. > And I'm still concerned that making these changes will be an > incompatible change, because the functions that signaled the error > right at the beginning will now do part of their job before > signaling, and that could affect the net result of calling them in > those cases. > > Why are you concerned? Which code do you think will break? The code which doesn't expect some of the jobs of those functions to be done when they eventually signal an error. > More specifically, have you ever seen or heard about a piece of code > using `inhibit-interaction`? I have not, *except* in the context of > bugs like this one. IOW, AFAICT, `inhibit-interaction` fails at > providing the only feature for which it's useful. See bug#13697, which was the motivation for introducing this variable. It mentions a couple of use cases, bug#6567 and bug#25214. > We have a kind of a mess when it comes to waiting for external events: > if you look at various pieces of code that have to do such waits, you'll > tend to see that they all do it a bit differently, and if you look at > the surrounding comments and Git history, you'll tend to see that it's > the result of frustrating trial-and-failure bumping into various corner > cases. The fact that `sit-for` currently allows async processes in > interactive mode but not in batch mode is probably one of the sources of > such problems. I agree that we have a mess, but disagree that we should try to fix it. It's a mess we have been living with for decades, and I don't doubt that gobs of programs out there depend on this mess. > > With all due respect to our test suite, let's not forget that its main > > purpose is to allow us to test the various Emacs features. > > That doesn't mean that problems encountered while writing the test suite > (e.g. the fact that `sit-for` doesn't read from async processes when > used in batch) can't reflect real problems that also affect real code > and thus deserve changes in Emacs proper. Yes, but we need to be able to define those real problems. Just the fact that something interferes with the test suite itself is not enough. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 09:43:51 2024 Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 14:43:51 +0000 Received: from localhost ([127.0.0.1]:60577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbLux-0001lE-5J for submit@debbugs.gnu.org; Sat, 17 Feb 2024 09:43:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55980) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbLuu-0001l1-QZ for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 09:43:49 -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 ) id 1rbLuU-0003kl-K6; Sat, 17 Feb 2024 09:43:22 -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=REcC2XSvWZM2VgCJY2RjVF/BgcBA2DbIuPHlRdSjoMQ=; b=rJF27eE9ZI+o CHvSRsuCQGiuidiANmlvhH3nKlJCdRhd9Hn6+NrVEUHMSE4DRpKrfrIXH1TM98rupsTDXtX7vQCct K6WRCyLSsYia+6zAg0U9N6zKqJt5Y89Zc49TILqKHH23CStfpy2R9nAQJzfK9b8ird6/KvUDhBCJr bzUBpwyIAoaIfDJp3o95Yw/e/To+8uX/WZLZnZU9YiY0zbEFFG0V2PGt9aOVZniM3dzUc6uOI7Xae lEPLr/b/napLSwug6QDxD3Rt8AvllP6QsoxHohoE6x2Epd9Mf85GSDyQY2cPcbylUoXL87sNDZlso 8cRludZGwH3MMP/BK6KxsQ==; Date: Sat, 17 Feb 2024 16:43:20 +0200 Message-Id: <86le7jtalz.fsf@gnu.org> From: Eli Zaretskii To: monnier@iro.umontreal.ca, sbaugh@janestreet.com In-Reply-To: <86r0hbtayp.fsf@gnu.org> (message from Eli Zaretskii on Sat, 17 Feb 2024 16:35:42 +0200) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> <86frxrv85e.fsf@gnu.org> <86r0hbtayp.fsf@gnu.org> X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: larsi@gnus.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org > Date: Sat, 17 Feb 2024 16:35:42 +0200 > From: Eli Zaretskii > > > More specifically, have you ever seen or heard about a piece of code > > using `inhibit-interaction`? I have not, *except* in the context of > > bugs like this one. IOW, AFAICT, `inhibit-interaction` fails at > > providing the only feature for which it's useful. > > See bug#13697, which was the motivation for introducing this variable. > It mentions a couple of use cases, bug#6567 and bug#25214. Btw, I'm perfectly fine if we want to decide that the inhibit-interaction experiment failed, and remove it from Emacs. If you are right, and no one uses it out there yet, doing so will not cause any harm. We could then reopen the above bug, and either close it as wontfix or wait for a better solution to present itself. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 10:16:15 2024 Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 15:16:15 +0000 Received: from localhost ([127.0.0.1]:33584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbMQJ-0002vo-5X for submit@debbugs.gnu.org; Sat, 17 Feb 2024 10:16:15 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbMQG-0002vY-6h for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 10:16:12 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7F8311000C3; Sat, 17 Feb 2024 10:15:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708182941; bh=GC92R+RqcScoduT3KADph1nuJaNyEpfzecPiLb2X7hY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mA8j+GaypR7O5mzkq4W8jxC+AxupzTkGs0nxnfFgGuAfU0sheAfcVJV9qFgyCZEVb 34/NhbA7H85FWcuWEhxSzRwJKoNxQ13XA4nkIrbwL3OW3rErRN+u+kpMIN+joucqwR hV1UtZMuYtaJUcyZ6QNiYtD3+B2iEVlVfxBLtd+9ENzIJVHp9u/myA1kYQ9KfxHl7n 52xbxAJ/HAHtyW07dhiiY6j/NMUdLFiWsm9suOhoGqQ8Z4nzixMlspDYzA4uUhQId3 JbjDiQlZZQWUMqEX2PIDMBl08msktUNUKaHWMe1gBLw5uXhs1hsQrJiBVuLsh/cwua dVMB0aSy/jAXw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 36B3810004B; Sat, 17 Feb 2024 10:15:41 -0500 (EST) Received: from pastel (unknown [45.72.205.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 06C53120682; Sat, 17 Feb 2024 10:15:40 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros In-Reply-To: <86r0hbtayp.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Feb 2024 16:35:42 +0200") Message-ID: References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> <86frxrv85e.fsf@gnu.org> <86r0hbtayp.fsf@gnu.org> Date: Sat, 17 Feb 2024 10:15:39 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.118 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: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) >> I can't remember what Spencer's use case was, but for me the use case >> was simply that I was getting tired of having to kill Emacs processes >> that were hanging waiting for input while running the test suite. > ?? I bump into this from time to time, but a simple Ctrl-C usually > solves the problem on the spot. That works if you started the test suite directly from the command line "in the foreground", but I usually run it in the background detached from the tty. Also, there's the problem of having to decide whether it's hanging or whether it's just slow. Also, killing the hung Emacs process allows further tests to be run, whereas `C-c` would interrupt the whole testsuite. And of course, there's also the CI case where there really is noone to hit `C-c`. >> Why are you concerned? Which code do you think will break? > The code which doesn't expect some of the jobs of those functions to > be done when they eventually signal an error. Sorry, it's still too vague for me to understand what kind of scenario you're thinking if. For me, when we hit this error the only important thing to do is to report the problem and stop what we're doing. Rather than signal a Lisp error, I'd be OK with exiting the process. So the details of exactly when&where the error is signaled don't seem very relevant. >> More specifically, have you ever seen or heard about a piece of code >> using `inhibit-interaction`? I have not, *except* in the context of >> bugs like this one. IOW, AFAICT, `inhibit-interaction` fails at >> providing the only feature for which it's useful. > See bug#13697, which was the motivation for introducing this variable. > It mentions a couple of use cases, bug#6567 and bug#25214. Thanks. I don't see anything in these examples that shows they depend on the specific way the code currently works. Maybe for `bug#25214` we wouldn't want to exit the process altogether, but for everything else, the use case seems pretty much exactly the same as mine, with the same overarching goal: report the problem and stop what we're doing. > I agree that we have a mess, but disagree that we should try to fix > it. It's a mess we have been living with for decades, and I don't > doubt that gobs of programs out there depend on this mess. Should we rename Emacs-29.2 as Emacs-final, then? =F0=9F=99=82 >> > With all due respect to our test suite, let's not forget that its main >> > purpose is to allow us to test the various Emacs features. >> That doesn't mean that problems encountered while writing the test suite >> (e.g. the fact that `sit-for` doesn't read from async processes when >> used in batch) can't reflect real problems that also affect real code >> and thus deserve changes in Emacs proper. > Yes, but we need to be able to define those real problems. Of course. That's why I've been sitting on this `sit-for` change without reporting the problem, waiting to find a more real case where it bites us. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 11:08:18 2024 Received: (at 67837) by debbugs.gnu.org; 17 Feb 2024 16:08:18 +0000 Received: from localhost ([127.0.0.1]:33655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbNEf-0004Mi-Cx for submit@debbugs.gnu.org; Sat, 17 Feb 2024 11:08:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbNEc-0004Lx-V9 for 67837@debbugs.gnu.org; Sat, 17 Feb 2024 11:08:15 -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 ) id 1rbNEC-0003bq-7x; Sat, 17 Feb 2024 11:07:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=dlQ9sJ/57ALebbVK6M46cKBJ3XVoYJIuxaLL1NgkRpI=; b=fvoUPj5FKapkv0meijzc 6ap4gaBPlvHic2lM+kfD2gP1ogy2ow3ylXSWS4vOYusOKE8fEce6lvGisCiyVQeZzElkt3sDksW2c z9IqBpvn0Avb4s+Dq006iYT0y2Tx/WGyrjk1GS8M7V2J7746zxe6LeyrI0QdERORkDSAGA12ffkvx 308TBHzjbSJZr4C3vvB3sryE3B8wyDNK7/XdwmFxcxPElPGbsbYbfE4IuIDDYZlJ7B5XF93K7PfgB g97q1c5eJiXNBql+gJWh2GqV+F71bRnBGCqgrQWrqju8fLG0DEDj1P5tex/2CVfAnYlxaDmLKIedw 6q7f17S6HxhSpA==; Date: Sat, 17 Feb 2024 18:07:45 +0200 Message-Id: <86frxrt6pa.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 17 Feb 2024 10:15:39 -0500) Subject: Re: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros References: <83le9vnvnn.fsf@gnu.org> <83jzpfnsle.fsf@gnu.org> <83h6kjnrzg.fsf@gnu.org> <86frxrv85e.fsf@gnu.org> <86r0hbtayp.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 67837 Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > From: Stefan Monnier > Cc: sbaugh@janestreet.com, larsi@gnus.org, 67837@debbugs.gnu.org > Date: Sat, 17 Feb 2024 10:15:39 -0500 > > >> I can't remember what Spencer's use case was, but for me the use case > >> was simply that I was getting tired of having to kill Emacs processes > >> that were hanging waiting for input while running the test suite. > > ?? I bump into this from time to time, but a simple Ctrl-C usually > > solves the problem on the spot. > > That works if you started the test suite directly from the command line > "in the foreground", but I usually run it in the background detached from > the tty. So now we need to pay for the strange ways you run the test suite? > Also, there's the problem of having to decide whether it's hanging > or whether it's just slow. That is never a problem for me: just look at the "top" display or similar. > Also, killing the hung Emacs process allows further tests to be run, > whereas `C-c` would interrupt the whole testsuite. Not necessarily. IME, it usually interrupts only the test that's being run. > And of course, there's also the CI case where there really is noone > to hit `C-c`. Maybe we should ask Michael, but AFAIK CI frameworks are prepared to deal with such contingencies. > >> Why are you concerned? Which code do you think will break? > > The code which doesn't expect some of the jobs of those functions to > > be done when they eventually signal an error. > > Sorry, it's still too vague for me to understand what kind of scenario > you're thinking if. > > For me, when we hit this error the only important thing to do is to > report the problem and stop what we're doing. Rather than signal a Lisp > error, I'd be OK with exiting the process. So the details of exactly > when&where the error is signaled don't seem very relevant. If you exit the process, then I agree, the rest is not important. But exiting is too drastic, and will be frowned upon, so we shouldn't do that. And if we only signal an error, then any code that runs before it could have effect that previously didn't happen -- that's the scenario I'm thinking of. > > I agree that we have a mess, but disagree that we should try to fix > > it. It's a mess we have been living with for decades, and I don't > > doubt that gobs of programs out there depend on this mess. > > Should we rename Emacs-29.2 as Emacs-final, then? 🙂 No. Risking breakage when adding new useful features is justified. Risking breakage to cater to oddball use cases isn't. Emacs is still being developed, but it isn't a student project, where people should be free to experiment all they like. We have users out there who rely on us to not destabilize Emacs unless we absolutely have to, for much greater good.