From unknown Fri Jun 20 07:27:51 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#67393 <67393@debbugs.gnu.org> To: bug#67393 <67393@debbugs.gnu.org> Subject: Status: 29.1; Slow to open file if autosave exists Reply-To: bug#67393 <67393@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:27:51 +0000 retitle 67393 29.1; Slow to open file if autosave exists reassign 67393 emacs submitter 67393 materus213 severity 67393 normal tag 67393 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 22 19:34:30 2023 Received: (at submit) by debbugs.gnu.org; 23 Nov 2023 00:34:30 +0000 Received: from localhost ([127.0.0.1]:60174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5xfo-0006nf-Je for submit@debbugs.gnu.org; Wed, 22 Nov 2023 19:34:30 -0500 Received: from lists.gnu.org ([2001:470:142::17]:42686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5xae-0006de-Av for submit@debbugs.gnu.org; Wed, 22 Nov 2023 19:29:11 -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 1r5xaO-0000Q8-Ly for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 19:28:53 -0500 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r5xZs-0004Qn-9v for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 19:28:44 -0500 Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-507a62d4788so450150e87.0 for ; Wed, 22 Nov 2023 16:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700699296; x=1701304096; darn=gnu.org; h=content-transfer-encoding:from:content-language:subject:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=b66K3CNZgLhxt1j3L5aIO+QTmyK8uofZYawV0odKZiE=; b=WFdK3/zXfh0N00YCAierGsdti4w1zD9EyT8ixDUk7nAftKlNkOPPqt93wUNsnU/s8R HF9SR4Qm2jSoQ03w+ihnwH+c6wBQhe/KC+qAHNnmuNvpykLWBPPXzOb+25qo7sW2c0Gc e85AAdT7TGm1Dc6zCdcI+6o+t6ZnItthvR48kyorOOq4LDmt2knKuG2G3bkmel9q7RWa M6Ztlb99rzM1rCBmy+LBVBr68Myzv5HOe4z0nMaKUOdrDR00XddXcA6SOD3lB/Z3oamC LAuNZH2VwdnRERaXBlwnkG5fmqzivpkfUW4rFY3oesZWxP6zaHFd2b0pRkN12m2D5vUw Qx+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700699296; x=1701304096; h=content-transfer-encoding:from:content-language:subject:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=b66K3CNZgLhxt1j3L5aIO+QTmyK8uofZYawV0odKZiE=; b=rqxQNDMcjn0nnG1UBr9nAlRjMzpXKMxZsAQ2zp1EeJ/C7XBfz2WcY12drdmO9L4084 IKamNV6o9eJ2/zo4bQxaHlRBUPjAEy0mBpHZ+XdHpMC1/pUPrDGpkqh01BrcEEy1DgWn SoY76CJv84J+Yhqh4FctFlzicqaXqVDjsT2B4DzwdoiV+YFIyOJqCr4yPZihHRsfeRAf GwPsGdAo3Tj05/QrcBuXi7dZ8rFcZ90KCmeH0SkBfpyHTVKaI049BX+bF0rxm7qXXi+b U9h8Z4C+3MUA9u+tFD8LotWH4Mls16gKJmPXCPVr9ZZX5Bns1ViaFTaSsYwQ+HJbKRKY c4Kg== X-Gm-Message-State: AOJu0Yz/sIS0Z3XN+IxBEo/auLsdVtFitHKk6QfkVvcSUVf2JRn+uHBj Gs7foMTxmlKVQFrLAMV6U2xX4nWWyq4= X-Google-Smtp-Source: AGHT+IHUNBGb4+RyQayYPOGR43VvWkuQJ+8YvaJ0Tl8X2e+P4IsYqtDny+9RhY2OtZySwF7S+jxYpA== X-Received: by 2002:a05:6512:41e:b0:507:c7ae:32cc with SMTP id u30-20020a056512041e00b00507c7ae32ccmr2790388lfk.41.1700699295010; Wed, 22 Nov 2023 16:28:15 -0800 (PST) Received: from [192.168.100.2] (xdsl-5170.walbrzych.dialog.net.pl. [84.40.231.50]) by smtp.gmail.com with ESMTPSA id l14-20020a1709060e0e00b00a0353fd24a5sm62484eji.184.2023.11.22.16.28.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Nov 2023 16:28:14 -0800 (PST) Message-ID: Date: Thu, 23 Nov 2023 01:28:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: bug-gnu-emacs@gnu.org Subject: 29.1; Slow to open file if autosave exists Content-Language: en-US From: materus213 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=materus213@gmail.com; helo=mail-lf1-x12f.google.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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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: 1.2 (+) 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: As in topic, emacs normally open files in instant, but when autosave (#filename#) exists, it takes about 1 sec to open file. It doesn't seem to be config problem since same happens with -Q flag. In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.18.0) Windowing system distributor 'The X.Org Foundation', version 11.0.12302002 System Description: NixOS 23.11 [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (materus213[at]gmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (materus213[at]gmail.com) -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 22 Nov 2023 19:34:27 -0500 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.2 (/) As in topic, emacs normally open files in instant, but when autosave (#filename#) exists, it takes about 1 sec to open file. It doesn't seem to be config problem since same happens with -Q flag. In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.18.0) Windowing system distributor 'The X.Org Foundation', version 11.0.12302002 System Description: NixOS 23.11 (Tapir) Configured using: 'configure --prefix=/nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft --with-cairo --with-native-compilation --with-imagemagick --with-tree-sitter --with-xinput2 --with-xwidgets' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB Important settings: value of $EMACSLOADPATH: value of $EMACSNATIVELOADPATH: value of $LANG: pl_PL.UTF-8 value of $XMODIFIERS: @im=fcitx locale-coding-system: utf-8-unix Major mode: Dashboard Minor modes in effect: delete-selection-mode: t pixel-scroll-precision-mode: t cua-mode: t minions-mode: t recentf-mode: t elcord-mode: t telephone-line-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/site-start hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/site-lisp/site-start /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/transient-20231121.1154/transient hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/transient /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package-core hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package-core /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/bind-key-20230203.2004/bind-key hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/bind-key /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package-ensure hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package-ensure /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package-bind-key hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package-bind-key /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package-lint hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package-lint /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package-jump hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package-jump /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package-delight hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package-delight /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20230426.2324/use-package-diminish hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/use-package/use-package-diminish /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-agenda hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-agenda /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-table hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-table /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-odt hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-odt /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-latex hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-latex /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-html hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-html /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-clock hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-clock /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-ascii hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-ascii /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-list hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-list /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-publish hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-publish /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-icalendar hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-icalendar /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-lint hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-lint /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-man hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-man /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-md hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-md /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-beamer hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-beamer /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-org hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-org /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-persist hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-persist /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-koma-letter hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-koma-letter /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-core hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-core /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-mobile hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-mobile /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-fold-core hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-fold-core /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-colview hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-colview /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-plot hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-plot /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-src hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-src /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-capture hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-capture /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-refile hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-refile /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-mouse hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-mouse /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-macs hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-macs /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-timer hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-timer /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-protocol hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-protocol /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-num hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-num /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-tempo hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-tempo /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-pcomplete hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-pcomplete /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-id hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-id /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-habit hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-habit /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-indent hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-indent /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-footnote hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-footnote /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-inlinetask hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-inlinetask /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-feed hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-feed /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-compat hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-compat /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-fortran hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-fortran /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-datetree hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-datetree /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-attach hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-attach /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-goto hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-goto /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-C hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-C /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-archive hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-archive /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-fold hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-fold /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-cycle hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-cycle /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-keys hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-keys /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-ctags hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-ctags /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-loaddefs hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-loaddefs /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-attach-git hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-attach-git /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-entities hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-entities /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-duration hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-duration /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-gnus hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-gnus /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-faces hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-faces /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-crypt hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-crypt /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-bibtex hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-bibtex /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-tangle hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-tangle /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/oc-basic hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/oc-basic /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-eww hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-eww /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/oc-csl hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/oc-csl /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-sql hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-sql /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-w3m hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-w3m /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-irc hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-irc /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-info hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-info /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-mhe hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-mhe /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-bbdb hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-bbdb /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-rmail hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-rmail /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-man hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-man /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/oc-biblatex hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/oc-biblatex /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-shell hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-shell /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-doi hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-doi /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-eshell hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-eshell /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol-docview hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol-docview /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-python hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-python /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/oc-natbib hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/oc-natbib /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-ruby hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-ruby /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-sqlite hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-sqlite /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-table hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-table /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/oc-bibtex hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/oc-bibtex /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-screen hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-screen /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-scheme hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-scheme /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-sed hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-sed /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-ref hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-ref /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-sass hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-sass /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-processing hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-processing /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-plantuml hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-plantuml /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-lua hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-lua /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-perl hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-perl /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-octave hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-octave /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-julia hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-julia /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-java hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-java /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-haskell hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-haskell /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-lob hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-lob /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-ocaml hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-ocaml /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-gnuplot hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-gnuplot /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-latex hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-latex /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-lilypond hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-lilypond /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-maxima hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-maxima /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-org hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-org /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-js hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-js /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-lisp hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-lisp /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-makefile hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-makefile /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-matlab hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-matlab /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-exp hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-exp /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-groovy hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-groovy /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-R hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-R /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-clojure hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-clojure /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-forth hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-forth /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-eval hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-eval /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-comint hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-comint /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-eshell hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-eshell /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-dot hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-dot /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-emacs-lisp hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-emacs-lisp /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-ditaa hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-ditaa /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-awk hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-awk /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-css hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-css /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ob-calc hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ob-calc /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-element hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-element /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ox-texinfo hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ox-texinfo /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/oc hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/oc /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/ol hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/ol /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-macro hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-macro /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6.12/org-version hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/org/org-version /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/cl-generic-0.3/cl-generic hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/emacs-lisp/cl-generic /nix/store/d8q5qq5h3sc4pykzwmsppd6jfd8g9cfy-emacs-packages-deps/share/emacs/site-lisp/elpa/eldoc-1.14.0/eldoc hides /nix/store/03gml4425bb8x4nnlhlwrs7pva3a156y-emacs-gtk3-29.1/share/emacs/29.1/lisp/emacs-lisp/eldoc Features: (shadow sort mail-extr emacsbug message yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr warnings finder-inf centaur-tabs-autoloads clipetty-autoloads cmake-mode-autoloads company-autoloads corfu-autoloads d-mode-autoloads dashboard-autoloads doom-themes-autoloads elcord-autoloads helm-autoloads helm-core-autoloads async-autoloads json-mode-autoloads json-snatcher-autoloads load-relative-autoloads lsp-haskell-autoloads haskell-mode-autoloads lsp-java-autoloads dap-mode-autoloads lsp-docker-autoloads bui-autoloads lsp-jedi-autoloads lsp-treemacs-autoloads lsp-ui-autoloads lsp-mode-autoloads eldoc-autoloads f-autoloads markdown-mode-autoloads minimap-autoloads minions-autoloads moe-theme-autoloads multiple-cursors-autoloads nerd-icons-completion-autoloads nix-mode-autoloads org-rainbow-tags-autoloads org-review-autoloads org-roam-ui-autoloads org-roam-autoloads emacsql-autoloads org-autoloads persp-mode-autoloads popup-autoloads powerline-autoloads rainbow-delimiters-autoloads request-autoloads simple-httpd-autoloads spinner-autoloads telephone-line-autoloads tree-edit-autoloads reazon-autoloads treemacs-icons-dired-autoloads treemacs-magit-autoloads magit-autoloads pcase magit-section-autoloads git-commit-autoloads transient-autoloads treemacs-nerd-icons-autoloads nerd-icons-autoloads treemacs-perspective-autoloads perspective-autoloads treemacs-projectile-autoloads treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads hydra-autoloads lv-autoloads pfuture-autoloads ace-window-autoloads avy-autoloads s-autoloads dash-autoloads projectile-autoloads use-package-autoloads bind-key-autoloads vertico-autoloads vterm-autoloads websocket-autoloads wfnames-autoloads with-editor-autoloads info compat-autoloads yaml-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 cl-extra help-mode org-agenda org-element org-persist xdg org-id avl-tree generator org-refile org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete comint ansi-osc ansi-color org-list org-footnote org-faces org-entities time-date noutline outline icons ob-emacs-lisp ob-core ob-eval org-cycle org-table org-keys oc org-loaddefs find-func cal-menu calendar cal-loaddefs ol rx org-fold org-fold-core org-compat org-version org-macs format-spec bookmark text-property-search pp time delsel pixel-scroll cua-base ring doom-horizon-theme minions compat dashboard dashboard-widgets recentf tree-widget wid-edit ffap thingatpt url-parse auth-source password-cache url-vars elcord json map bindat telephone-line telephone-line-segments telephone-line-separators telephone-line-utils cl-seq subr-x eieio byte-opt bytecomp byte-compile eieio-core cl-macs gv color doom-themes doom-themes-base 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 xwidget-internal dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 280735 281598) (symbols 48 19971 39) (strings 32 65361 34738) (string-bytes 1 2460971) (vectors 16 35285) (vector-slots 8 647471 362628) (floats 8 494 1457) (intervals 56 445 300) (buffers 984 14)) From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 23 01:51:55 2023 Received: (at 67393) by debbugs.gnu.org; 23 Nov 2023 06:51:55 +0000 Received: from localhost ([127.0.0.1]:60425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r63Z4-0003Jj-Sb for submit@debbugs.gnu.org; Thu, 23 Nov 2023 01:51:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r63Z2-0003JE-P0; Thu, 23 Nov 2023 01:51:53 -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 1r63Yt-0006Xm-NS; Thu, 23 Nov 2023 01:51:43 -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=3eiyb7XITfQT001Lq3ZMklOEhG3chH1SY3L2eAJzlcw=; b=BzL6l4L0rj50 RJhYiuyxXrNtZj4wvE3ORzL67bLfOBOc7BltqultZt+EXQEbrJpA8HCJqhpgXlvGTWfDwJ8y7IPru +FQNM4pPdCQbLtf8W+/S5Nxf6R4h6pBWgX3HTM22ZrPfc6dyRWGzDJBSaxd+0AixLcB6XUeqZAgs6 jEgI2LDHyKdUs3h+xDSKTC458MEPGFOZpy5bzgeEI95yEwIwAbp4HdzP/VrA8pJhzP0ADpjZlGMgO NJFFUgaN4YRiSp3ony8m1/ai37Y9Z0H4qhWBHV89Ae0X6pGZTgHCkmqaibsRjToj6rdH3XEfhRcgZ 787tIX2fwZSfc3uwFtxrow==; Date: Thu, 23 Nov 2023 08:51:35 +0200 Message-Id: <83a5r5gdxk.fsf@gnu.org> From: Eli Zaretskii To: materus213 In-Reply-To: (message from materus213 on Thu, 23 Nov 2023 01:28:13 +0100) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: 67393@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 (---) tags 67393 notabug thanks > Date: Thu, 23 Nov 2023 01:28:13 +0100 > From: materus213 > > As in topic, emacs normally open files in instant, but when autosave > (#filename#) exists, it takes about 1 sec to open file. > It doesn't seem to be config problem since same happens with -Q flag. This is a feature: we let the user see the message and wait for 1 sec after showing it, to make sure this particular message is not immediately replaced by some others. From after-find-file: (when (and warn msg) (message "%s" msg) (or not-serious (sit-for 1 t)))) ^^^^^^^^^^^^^ (The value of not-serious is nil in this case.) This is not a bug. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 22 09:56:26 2023 Received: (at 67393-done) by debbugs.gnu.org; 22 Dec 2023 14:56:26 +0000 Received: from localhost ([127.0.0.1]:47518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGgws-0003yd-8n for submit@debbugs.gnu.org; Fri, 22 Dec 2023 09:56:26 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:54316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGgwp-0003yR-Op for 67393-done@debbugs.gnu.org; Fri, 22 Dec 2023 09:56:24 -0500 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-553eb74df60so2145937a12.0 for <67393-done@debbugs.gnu.org>; Fri, 22 Dec 2023 06:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703256973; x=1703861773; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=1ysSKXFytSNT+y3FgFySze1SQtSJDbq2sLU0lFuenBU=; b=ETNplpf+EZQjiXjJmxeZUlr/LT7I1immFltYuquU22CCsC0DHmZkG+3LUyzwWKl+Mf R3kdqy/+se2wjDX1/XEXUBB+U0ma00u8CnBwmixp7ZbT2rofANTGmR7SMbTmbUF6TDDz D2VNQA81KdM88RQDarJk++YT/b03Eab2082214aIMWNdWi6qBqOWzaF4ZhuqACbWobM0 zXSqtH1pC2raUEwRUI2giJ3/uRSF+c8giNLO4eoP3OLoAmRjMBh5T4d7QZMR6BDGJVq8 Yq06W6+oAcOMhmd23sTlPCs988TE1ic95tJKmnt6/nbaP8jaxXIYCkF8jn4HcquLg3aI Uh1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703256973; x=1703861773; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1ysSKXFytSNT+y3FgFySze1SQtSJDbq2sLU0lFuenBU=; b=jjkii5Hff9Ocec10eFL+uI9ZepChhGxB7mpyfHuhtsTvaqKd7wJwKA37GNNaV5tQML l9BQSo5vFMBTuySRJCraG0eAdjTQckIgLIDCbJnof2P1ONdr2PwBFheHJOWLH/GbGKMN fmAFU4jkbgF1hiaJFEGgV1G07VoifXHzFrcIAOk6pXl5GomOuC5GRvkdxzi/GifVpg8O uJDvpF+LwHLpbVTF1IOpxVkokenbn/aZSVyvnnlq3fNrzBxayTxHEQjs6jTT7Y5MhvFz 8hNX0f9fsz8gJZfYBJW+ue25VluF3KTZIa3gieEK9urkJ14FXiHRYzUOO9EzIMSioJOS LXEQ== X-Gm-Message-State: AOJu0YxtTkx857Vxn0XUGdjlDdlBGEdBcZ5LZveI6fAauXomepFOHCJg ZdCnbLW0fUt4iu6dejcHRYPQ47mZMeuK0IPuRes= X-Google-Smtp-Source: AGHT+IG8IydDa/sm58TxmPrx9STA3vk5vQrD1ka8EZpLLsSoK10/ShHBPgpUqGzBUCvPknWX7jnVQ3budVPtsefsKLI= X-Received: by 2002:a50:c354:0:b0:553:43e3:df2e with SMTP id q20-20020a50c354000000b0055343e3df2emr840679edb.60.1703256973433; Fri, 22 Dec 2023 06:56:13 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Dec 2023 06:56:13 -0800 From: Stefan Kangas In-Reply-To: <83a5r5gdxk.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Nov 2023 08:51:35 +0200") References: <83a5r5gdxk.fsf@gnu.org> MIME-Version: 1.0 Date: Fri, 22 Dec 2023 06:56:13 -0800 Message-ID: Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67393-done Cc: materus213 , 67393-done@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: -1.0 (-) Eli Zaretskii writes: > tags 67393 notabug > thanks > >> Date: Thu, 23 Nov 2023 01:28:13 +0100 >> From: materus213 >> >> As in topic, emacs normally open files in instant, but when autosave >> (#filename#) exists, it takes about 1 sec to open file. >> It doesn't seem to be config problem since same happens with -Q flag. > > This is a feature: we let the user see the message and wait for 1 sec > after showing it, to make sure this particular message is not > immediately replaced by some others. From after-find-file: > > (when (and warn msg) > (message "%s" msg) > (or not-serious (sit-for 1 t)))) > ^^^^^^^^^^^^^ > (The value of not-serious is nil in this case.) > > This is not a bug. I'm therefore closing this bug report. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 23 09:31:22 2023 Received: (at 67393-done) by debbugs.gnu.org; 23 Dec 2023 14:31:23 +0000 Received: from localhost ([127.0.0.1]:48835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rH322-0004EC-Ua for submit@debbugs.gnu.org; Sat, 23 Dec 2023 09:31:22 -0500 Received: from mout02.posteo.de ([185.67.36.66]:45843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rH321-00045f-4b for 67393-done@debbugs.gnu.org; Sat, 23 Dec 2023 09:31:13 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 26468240104 for <67393-done@debbugs.gnu.org>; Sat, 23 Dec 2023 15:31:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703341862; bh=7+T5Tb2O8kUbyJ05SewzLhFNld4GCSePkffkPBXg8Jc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=sAEd9WnJDfJ6Jz1y99CdUeGpJh5T2PF3QTt0BkNmBoGSmLyvupn9TY9sVDebrV/uX AjC/asdpl8PoI4uhXVq2rVdYNamE4SCAQDhOEqfKDELKxl251ZK0w8Kfhpq/RpSoRz 4BeWljPlD3Jj9VxWGf/6D5UwNLB9DOzQrvhgmg45GGc86zCG5ub0rf04ScpZtz/nE0 WkZFHO/zr/AfXq35PPoM2rwmz7DEhETn68UnJ6htxsdtogB1+wvYxQoB4iy5Lu7xSX XZvvoQQ674uC1GL/8rTXjCZH8L4B+wgc0JSG+34gT+HRPYovbHl6REUcjMcvtzbRDy wOecm6u/rdMWQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Sy66F46M6z9rxG; Sat, 23 Dec 2023 15:31:01 +0100 (CET) From: Ihor Radchenko To: Stefan Kangas Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: References: <83a5r5gdxk.fsf@gnu.org> Date: Sat, 23 Dec 2023 14:34:13 +0000 Message-ID: <87frztc7iy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393-done Cc: materus213 , Eli Zaretskii , 67393-done@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 (---) Stefan Kangas writes: >> This is a feature: we let the user see the message and wait for 1 sec >> after showing it, to make sure this particular message is not >> immediately replaced by some others. From after-find-file: >> >> (when (and warn msg) >> (message "%s" msg) >> (or not-serious (sit-for 1 t)))) >> ^^^^^^^^^^^^^ >> (The value of not-serious is nil in this case.) >> >> This is not a bug. > > I'm therefore closing this bug report. This is indeed not a bug, but I am wondering if it would be better to utilize `set-multi-message' somehow. We are certainly able to display multiple recent messages in the echo area. Then, why not allow to keep more important ones visible for a time period without blocking? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 23 12:37:00 2023 Received: (at 67393) by debbugs.gnu.org; 23 Dec 2023 17:37:00 +0000 Received: from localhost ([127.0.0.1]:51144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rH5vo-0007LU-3e for submit@debbugs.gnu.org; Sat, 23 Dec 2023 12:37:00 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:57753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rH5vm-0007LF-Uz for 67393@debbugs.gnu.org; Sat, 23 Dec 2023 12:36:59 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id D7D9560002; Sat, 23 Dec 2023 17:36:46 +0000 (UTC) From: Juri Linkov To: Ihor Radchenko Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <87frztc7iy.fsf@localhost> (Ihor Radchenko's message of "Sat, 23 Dec 2023 14:34:13 +0000") Organization: LINKOV.NET References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> Date: Sat, 23 Dec 2023 19:23:14 +0200 Message-ID: <867cl4kg4l.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67393 Cc: materus213 , Eli Zaretskii , 67393@debbugs.gnu.org, Stefan Kangas 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.7 (-) >>> This is a feature: we let the user see the message and wait for 1 sec >>> after showing it, to make sure this particular message is not >>> immediately replaced by some others. From after-find-file: >>> >>> (when (and warn msg) >>> (message "%s" msg) >>> (or not-serious (sit-for 1 t)))) >>> ^^^^^^^^^^^^^ >>> (The value of not-serious is nil in this case.) >>> >>> This is not a bug. >> >> I'm therefore closing this bug report. > > This is indeed not a bug, but I am wondering if it would be better to > utilize `set-multi-message' somehow. We are certainly able to display > multiple recent messages in the echo area. Then, why not allow to keep > more important ones visible for a time period without blocking? It's not easy to temporarily enable `set-multi-message', since it's not clear at what moment to disable it afterwards. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 23 13:02:41 2023 Received: (at 67393) by debbugs.gnu.org; 23 Dec 2023 18:02:41 +0000 Received: from localhost ([127.0.0.1]:51187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rH6Kf-0004s6-FR for submit@debbugs.gnu.org; Sat, 23 Dec 2023 13:02:41 -0500 Received: from mout02.posteo.de ([185.67.36.66]:36717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rH6Kd-0004rs-MV for 67393@debbugs.gnu.org; Sat, 23 Dec 2023 13:02:40 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 2D6C4240101 for <67393@debbugs.gnu.org>; Sat, 23 Dec 2023 19:02:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703354548; bh=kBxu954k4GpLW8gkGdInJFJNnX8ZogPjfZpT23svtXk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Kt4zkGbdYQWvxkkV8R8wfV8p0iOn7t58TbZceokXmfeBZ6rNqAaYa0Mc4txeuRt8z WXnvR6Vb+8b90+CSpT9eTCPqBozZgKmI9JBtYmBnebawGRekY5f4ulNYPpG5je9QQ7 NPvKqgBgP+uEVkE41Yw+EtWnyT76OKMs+qwPMv+dzMyhty2bu7nwSrxCvMVsasrreU 1qPJVFP0sETRE+piQ7z+9Ia8YuBYaXSHOMqNllkWOe5sbcDchRVXbo9HQawhfVzOQA sT9bAo452JyqLPsFYnTOA0RScIafl1hHpeNXK/IXhHGep93dJLql3IxANNYzwXHgNv 1F/fmKOfCFRhw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SyBpB70B8z9rxD; Sat, 23 Dec 2023 19:02:26 +0100 (CET) From: Ihor Radchenko To: Juri Linkov Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <867cl4kg4l.fsf@mail.linkov.net> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> Date: Sat, 23 Dec 2023 18:05:35 +0000 Message-ID: <87cyuwdcb4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213 , Eli Zaretskii , 67393@debbugs.gnu.org, Stefan Kangas 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 (---) Juri Linkov writes: >> This is indeed not a bug, but I am wondering if it would be better to >> utilize `set-multi-message' somehow. We are certainly able to display >> multiple recent messages in the echo area. Then, why not allow to keep >> more important ones visible for a time period without blocking? > > It's not easy to temporarily enable `set-multi-message', > since it's not clear at what moment to disable it afterwards. What I meant is to change the default `set-message-function' in such a way that it displays "important" messages for a custom time period, in addition to the last message. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 24 12:44:11 2023 Received: (at 67393) by debbugs.gnu.org; 24 Dec 2023 17:44:11 +0000 Received: from localhost ([127.0.0.1]:53487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHSWI-0002D0-Ss for submit@debbugs.gnu.org; Sun, 24 Dec 2023 12:44:11 -0500 Received: from relay7-d.mail.gandi.net ([2001:4b98:dc4:8::227]:58219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHSWD-0002CF-Pm for 67393@debbugs.gnu.org; Sun, 24 Dec 2023 12:44:09 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id DA13D20002; Sun, 24 Dec 2023 17:43:51 +0000 (UTC) From: Juri Linkov To: Ihor Radchenko Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <87cyuwdcb4.fsf@localhost> (Ihor Radchenko's message of "Sat, 23 Dec 2023 18:05:35 +0000") Organization: LINKOV.NET References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> Date: Sun, 24 Dec 2023 19:34:53 +0200 Message-ID: <868r5jse0m.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67393 Cc: materus213 , Eli Zaretskii , 67393@debbugs.gnu.org, Stefan Kangas 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.7 (-) >>> This is indeed not a bug, but I am wondering if it would be better to >>> utilize `set-multi-message' somehow. We are certainly able to display >>> multiple recent messages in the echo area. Then, why not allow to keep >>> more important ones visible for a time period without blocking? >> >> It's not easy to temporarily enable `set-multi-message', >> since it's not clear at what moment to disable it afterwards. > > What I meant is to change the default `set-message-function' in such a > way that it displays "important" messages for a custom time period, in > addition to the last message. I agree. The most annoying delay is in 'ispell-parse-output': (ding) ; error message from ispell! (message "Ispell error: %s" output) (sit-for 5) So I need to waste 5 seconds several times during spell-checking. It would be nicer to prepend this error message to any last displayed message during these 5 seconds. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 24 13:39:42 2023 Received: (at 67393) by debbugs.gnu.org; 24 Dec 2023 18:39:42 +0000 Received: from localhost ([127.0.0.1]:53507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHTO0-0005gC-RZ for submit@debbugs.gnu.org; Sun, 24 Dec 2023 13:39:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHTNu-0005ft-Mb for 67393@debbugs.gnu.org; Sun, 24 Dec 2023 13:39: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 1rHTNh-0004FM-61; Sun, 24 Dec 2023 13:39: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=9SLJvTqdqCg2XDmiyIxR0ZTUmxDKaMZnKmpv1B4pAO4=; b=pTm+D8HwmMKr 6FlVNYBc5HJ2kxnGePF+kJVZMAebzXxYUc7ZEs4XMtW7JcLkDnfdYsFE9K9vzbNFMZZM7otIbdRCG 7nttYoBxznP1ULwVEwNxSwQT+0d6InHsFC7721tHRh+bfoRpwNAQazs7AZnm3ckOXFdfEqMT08Hkb 85gQKjG0Mhfje2MG8Q8ZK14nXmgfiDpuCT9RlIX0n4MFDzH0TJRA5CV5fbTkqfK3npHQERDSR4B2x GpPV53MxwVragRHleL2bHOHWELBhXKEAKWZOGkzYqpHZ6WtefUZKBgpSLrM+WkphgD/D8ZMPZMz2E M5Io57vkad7lNSFlCNTgbQ==; Date: Sun, 24 Dec 2023 20:39:16 +0200 Message-Id: <83r0jbbg2z.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <868r5jse0m.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 24 Dec 2023 19:34:53 +0200) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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: Juri Linkov > Cc: Stefan Kangas , materus213 > , Eli Zaretskii , > 67393@debbugs.gnu.org > Date: Sun, 24 Dec 2023 19:34:53 +0200 > > >>> This is indeed not a bug, but I am wondering if it would be better to > >>> utilize `set-multi-message' somehow. We are certainly able to display > >>> multiple recent messages in the echo area. Then, why not allow to keep > >>> more important ones visible for a time period without blocking? > >> > >> It's not easy to temporarily enable `set-multi-message', > >> since it's not clear at what moment to disable it afterwards. > > > > What I meant is to change the default `set-message-function' in such a > > way that it displays "important" messages for a custom time period, in > > addition to the last message. > > I agree. The most annoying delay is in 'ispell-parse-output': > > (ding) ; error message from ispell! > (message "Ispell error: %s" output) > (sit-for 5) > > So I need to waste 5 seconds several times during spell-checking. Only when there's an error, right? > It would be nicer to prepend this error message to any last displayed > message during these 5 seconds. We don't really know whether doing that will be effective. Given N lines of messages in the echo-area, what are the chances that the user will see all of them, or even the most important one(s)? IOW, we don't have any real experience with this kind of UI. We need to collect such experience first, before we conclude that this could be used as an alternative to sit-for. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 24 14:00:07 2023 Received: (at 67393) by debbugs.gnu.org; 24 Dec 2023 19:00:07 +0000 Received: from localhost ([127.0.0.1]:53523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHThm-0000eG-Hk for submit@debbugs.gnu.org; Sun, 24 Dec 2023 14:00:07 -0500 Received: from mout01.posteo.de ([185.67.36.65]:56759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHThg-0000QF-Gd for 67393@debbugs.gnu.org; Sun, 24 Dec 2023 14:00:04 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id CD5CE240028 for <67393@debbugs.gnu.org>; Sun, 24 Dec 2023 19:59:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703444388; bh=KE+pCQUyX8aYGd9uK0HEtbpU7al9jOacCvIZxUBCCmE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=cpiKruy/Cmk4ciCVPyMEVRHJIaxm7Qq5bY+cws9Jv9WW+Kov1X+ysSuD8qrQV4tev AGrQ7CvN3xtmLBBFbtMMntrVXaEQe86zNAO2ca5ZDNNmk/42lEczBGcOO4tWzswTXE QUFTWhD+7QaANrq59bCoIHliD6nYVc7acv0oJeUrQJ0d7JNoofSB4jkxLxQwtI/DfS KJPYG6VgcdoPN85YaoXgscJkqPqvhL2BxJsx8nhGUkfJhbuMCZBql8iEpv445Bs0Ii FaqxG1KR4ce3E0zNtkmyU1twpRcDKaIforfm8iZYBTmAj816sOjJ5Ux65FfkH3RbGt 0DQa6R4NpQGKA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Syr1v6xfkz9rxF; Sun, 24 Dec 2023 19:59:47 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83r0jbbg2z.fsf@gnu.org> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> Date: Sun, 24 Dec 2023 19:03:00 +0000 Message-ID: <87mstz1l0b.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, Juri Linkov 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 (---) Eli Zaretskii writes: >> It would be nicer to prepend this error message to any last displayed >> message during these 5 seconds. > > We don't really know whether doing that will be effective. Given N > lines of messages in the echo-area, what are the chances that the user > will see all of them, or even the most important one(s)? AFAIU, the only difference is that `sit-for' will block Emacs, while the proposed multiline echo will not. Is absence of blocking what you are concerned about? As an alternative idea, important messages may have an option to be accumulated forever, until explicitly dismissed. Just like (notifications-notify :title "Very important message" :timeout 0) > IOW, we don't have any real experience with this kind of UI. We need > to collect such experience first, before we conclude that this could > be used as an alternative to sit-for. May we use the known experience with OS notifications? If not, do you have something specific in mind about collecting the experience? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 24 14:28:29 2023 Received: (at 67393) by debbugs.gnu.org; 24 Dec 2023 19:28:29 +0000 Received: from localhost ([127.0.0.1]:53544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHU9E-0006XM-Vl for submit@debbugs.gnu.org; Sun, 24 Dec 2023 14:28:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHU9B-0006X1-5Q for 67393@debbugs.gnu.org; Sun, 24 Dec 2023 14:28: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 1rHU8w-0005QK-5j; Sun, 24 Dec 2023 14:28:10 -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=7ZU/+XgN2FUFsvxcBJHwTObDi0iw9GniVNTxkkyRs+w=; b=SqANakYEzyFr Rdk5MXbnP1g7GKn5e2jAhdXydtNvVZwyB9LS3Mn1SbtZ6ZAeiUG3IVfAPIRhiapsIbgFYn43PNbox tjEvCO0x3KlYG6ORWIbGPo/rVCf1gdJ6fBY0Dmuc9V2PqSFAgwGUYI8LEJkLiJn/4+gDBZxzs3voP cEgciAj0ase8W35vFsnaI6GcK2haRba7m6HF+omTWKogDhXDC3vpcZ6JCA4UWHO54P61VsFaRoLK7 338rYtVO6XB3BMqLV1N90eyNzANAZH3SYrpQjB6fGEBR/zCRVPJwMOh/4COKHC2WI00qGd9mCt32q O+fxZBqFvj7J7C9YUhCOtA==; Date: Sun, 24 Dec 2023 21:28:03 +0200 Message-Id: <83bkafbdto.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87mstz1l0b.fsf@localhost> (message from Ihor Radchenko on Sun, 24 Dec 2023 19:03:00 +0000) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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: Ihor Radchenko > Cc: Juri Linkov , stefankangas@gmail.com, > materus213@gmail.com, 67393@debbugs.gnu.org > Date: Sun, 24 Dec 2023 19:03:00 +0000 > > Eli Zaretskii writes: > > >> It would be nicer to prepend this error message to any last displayed > >> message during these 5 seconds. > > > > We don't really know whether doing that will be effective. Given N > > lines of messages in the echo-area, what are the chances that the user > > will see all of them, or even the most important one(s)? > > AFAIU, the only difference is that `sit-for' will block Emacs, while the > proposed multiline echo will not. Is absence of blocking what you are > concerned about? No, I'm concerned with the span of user's attention when presented with multiple unrelated messages in several lines. > As an alternative idea, important messages may have an option to be > accumulated forever, until explicitly dismissed. Just like > (notifications-notify :title "Very important message" :timeout 0) How is this better than waiting for a second? > do you have something specific in mind about collecting the > experience? Use them for some unimportant messages until we have enough experience and can make intelligent decisions. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 24 14:46:29 2023 Received: (at 67393) by debbugs.gnu.org; 24 Dec 2023 19:46:30 +0000 Received: from localhost ([127.0.0.1]:53582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHUQf-0003qh-Er for submit@debbugs.gnu.org; Sun, 24 Dec 2023 14:46:29 -0500 Received: from mout02.posteo.de ([185.67.36.66]:55233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHUQc-0003ix-1x for 67393@debbugs.gnu.org; Sun, 24 Dec 2023 14:46:27 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 16177240103 for <67393@debbugs.gnu.org>; Sun, 24 Dec 2023 20:46:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703447174; bh=ZplzrtyPd76tYG8qQF4KqtF1u45xcFIGEKR8UbEWtGE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ddhyLdgmRHP/e863o2RwduFAlBFbVcQkzm34gpguuJ2s+CgsgvC/+nz5ONosFRCgT K8PKucX0mKwG1iIcMDoYGZXauvyiWS9xO1q2Ei6kElcri9cBsyrcagoYhUVLjSXCWD kQyyQW1OKnef83CmJU7QklRie6GJqgOcS1LHchpo36eZO4EjcTtlX6ZAFOWJYOo3HP elbRfcwCxOGmOJeZdgkZ2bnLYguoYbaL3yCvJD3TVZ9m3hnQJPEQqkkGgmlCdXYyHt Kx0qlvcFZOSdqnmJq8hYo6E8MUn/MHLJ5uBNNvUq1NMl7l3z7H6lwwBUTNI5zxYiQ/ cKwpnernhT/cQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Sys3T4Bscz6txc; Sun, 24 Dec 2023 20:46:13 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83bkafbdto.fsf@gnu.org> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> Date: Sun, 24 Dec 2023 19:49:26 +0000 Message-ID: <87bkaf1iux.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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 (---) Eli Zaretskii writes: >> AFAIU, the only difference is that `sit-for' will block Emacs, while the >> proposed multiline echo will not. Is absence of blocking what you are >> concerned about? > > No, I'm concerned with the span of user's attention when presented > with multiple unrelated messages in several lines. Then, the "important" messages should be written in such a way that they can be understood later, away from the immediate context of the message trigger. >> As an alternative idea, important messages may have an option to be >> accumulated forever, until explicitly dismissed. Just like >> (notifications-notify :title "Very important message" :timeout 0) > > How is this better than waiting for a second? 1. Waiting for a second creates a temptation to press C-g without thinking and get the original message replaced with "Quit". 2. The message can be read later (not just within one second). For example after a distraction in RL and being away from Emacs or a short moment. >> do you have something specific in mind about collecting the >> experience? > > Use them for some unimportant messages until we have enough experience > and can make intelligent decisions. Any specific messages in mind? If not, we may ask the users of set-multi-message. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 24 15:19:42 2023 Received: (at 67393) by debbugs.gnu.org; 24 Dec 2023 20:19:42 +0000 Received: from localhost ([127.0.0.1]:53620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHUwo-0001Wf-6l for submit@debbugs.gnu.org; Sun, 24 Dec 2023 15:19:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHUwm-0001WT-Ge for 67393@debbugs.gnu.org; Sun, 24 Dec 2023 15:19:41 -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 1rHUwZ-0006GK-Hs; Sun, 24 Dec 2023 15:19:27 -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=C2WTjQX4YrphSKoRIjie5iwqd5hwmA1zG2f7/LnYxTI=; b=AM0IN/G5/2oc zIdFWSP7KhglGad4w5gwAp1ouEJDzY1TDOFNuo7e+9X5nvKX5pptrbMzX4uPR7C5+dd6ItoI54tqk kyvFPqlFUE2/yPcBzoaQ9fgcaRaad+tX0VgIpnMlqfVpRU/5DDMgBxt+eDCk8WNYvvInLUP5QXQhk dsiMGh161WRUVP3WFKUivmcdCPch1nzFMqysiwi6878GKvteOB89mtv2rGWgrZXJYALbY0HDsntZi IQaycATjibXN2bCrOk84Kwxb5L2JcBacJI6ETXBvqNbmbuFTiamT3rPhoCuQy6MuAns5/1MgNQ9dq O/FngIRb5vMum7wgEusskw==; Date: Sun, 24 Dec 2023 22:19:20 +0200 Message-Id: <83a5pzbbg7.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87bkaf1iux.fsf@localhost> (message from Ihor Radchenko on Sun, 24 Dec 2023 19:49:26 +0000) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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: Ihor Radchenko > Cc: juri@linkov.net, stefankangas@gmail.com, materus213@gmail.com, > 67393@debbugs.gnu.org > Date: Sun, 24 Dec 2023 19:49:26 +0000 > > Eli Zaretskii writes: > > >> AFAIU, the only difference is that `sit-for' will block Emacs, while the > >> proposed multiline echo will not. Is absence of blocking what you are > >> concerned about? > > > > No, I'm concerned with the span of user's attention when presented > > with multiple unrelated messages in several lines. > > Then, the "important" messages should be written in such a way that they > can be understood later, away from the immediate context of the message > trigger. I don't think I understand what this means in practice. Can you show what will be displayed in the mini-window in this case, and how to make the "important" message stand out? > >> As an alternative idea, important messages may have an option to be > >> accumulated forever, until explicitly dismissed. Just like > >> (notifications-notify :title "Very important message" :timeout 0) > > > > How is this better than waiting for a second? > > 1. Waiting for a second creates a temptation to press C-g without > thinking and get the original message replaced with "Quit". > > 2. The message can be read later (not just within one second). For > example after a distraction in RL and being away from Emacs or a > short moment. Again: how will this look in practice, including the dismissal action? > >> do you have something specific in mind about collecting the > >> experience? > > > > Use them for some unimportant messages until we have enough experience > > and can make intelligent decisions. > > Any specific messages in mind? > If not, we may ask the users of set-multi-message. No specific messages in mind (and I don't think this aspect is important). From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 11:47:39 2023 Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 16:47:39 +0000 Received: from localhost ([127.0.0.1]:55221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHo78-0004dY-O1 for submit@debbugs.gnu.org; Mon, 25 Dec 2023 11:47:39 -0500 Received: from mout02.posteo.de ([185.67.36.66]:41557) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHo75-0004d4-03 for 67393@debbugs.gnu.org; Mon, 25 Dec 2023 11:47:37 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id CF7A3240104 for <67393@debbugs.gnu.org>; Mon, 25 Dec 2023 17:47:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703522841; bh=IWOaXr8Fe9C4ezkaT2hzLrHt5uqrzWysQ+l5Yu8lNwc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=jMa/mKT06lLn6XfZ4lbFFeVq6Bp1UbKOwiIOvc9ZumrscZj/BXvuvobGi36hDsrQy ICxXLAeY9GNsLQ2qIzwCoFr/YXr7w+Y/tWpgc+LnLizsz34gbmvEj1gxn6GeZv4Keb IXLxZWrF928Y9pUpuY0mYeNYplgtk4aGzBjnrbIf1FrHQoBl6n2ohwJCU8C3T1amHN 4e+6IEukhuLxGIFDy869o6GiKsfD1VWrgmfRds+8lEQ9+ziujI5KlAz9wh2o2DPpcV AQAnFi9EYvQs6vsJZ2itF39NUDsyYfWgh1yTi166PCiQbB3rgGVJEm6D6IdVpxV7CO YNhL0AVcO3uKA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SzP2d0zckz6twc; Mon, 25 Dec 2023 17:47:20 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83a5pzbbg7.fsf@gnu.org> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> Date: Mon, 25 Dec 2023 16:50:33 +0000 Message-ID: <87zfxymdk6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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 (---) Eli Zaretskii writes: >> Then, the "important" messages should be written in such a way that they >> can be understood later, away from the immediate context of the message >> trigger. > > I don't think I understand what this means in practice. Can you show > what will be displayed in the mini-window in this case, and how to > make the "important" message stand out? For example, the message "File exists, but cannot be read" from `after-find-file' may be written as "Opening file: exists, but cannot be read" >> > How is this better than waiting for a second? >>=20 >> 1. Waiting for a second creates a temptation to press C-g without >> thinking and get the original message replaced with "Quit". >>=20 >> 2. The message can be read later (not just within one second). For >> example after a distraction in RL and being away from Emacs or a >> short moment. > > Again: how will this look in practice, including the dismissal action? Try the following proof-of-concept code: (defvar important-message-list nil) (defun set-important-message (message) "Return the last message and previous important messages as one string. Individual messages will be separated by a newline and the last message wil= l be separated by \"--\". The previous messages will be displayed no longer than 'message-timeout pro= perty seconds (if 0 - forever). The previous messages may be dismissed via `remove-previous-message' command. Note that this feature works best only when `resize-mini-windows' is at its default value `grow-only'." (catch :continue (let ((last-message (car important-message-list)) (tail (cdr important-message-list))) (while last-message (let ((timeout (aref last-message 2))) (cond ((=3D timeout 0) (throw :continue t)) ((> (float-time) (+ (aref last-message 0) timeout)) (setq important-message-list (delete last-message important-mes= sage-list))))) (setq last-message (car tail) tail (cdr tail))))) (prog1 (if important-message-list (format "%s\n%s\n%s" (mapconcat (lambda (m) (aref m 1)) (reverse important-message-list) "\n") (make-string (frame-width) ?=E2=94=80) message) message) (when (get-text-property 0 'message-timeout message) (push (vector (float-time) (substring-no-properties (copy-sequence message)) (get-text-property 0 'message-timeout message)) important-message-list)))) (defun remove-previous-message (&optional n) "Remove the oldest important message displayed. With numeric prefix argument N, remove N's message." (interactive "p") (unless important-message-list (user-error "No important messages are dis= played.")) (let ((target (nth (or (and n (1+ n)) 0)))) (setq important-message-list (delete target important-message-list)))) (setq set-message-function #'set-important-message) (message (propertize "This is a test!" 'message-timeout 0)) (message (propertize "This will disappear in 3 seconds" 'message-timeout 3)) (message "foo") ;; M-x remove-previous-message to remove the displayed message. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 11:58:51 2023 Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 16:58:51 +0000 Received: from localhost ([127.0.0.1]:55242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHoHy-00050x-SK for submit@debbugs.gnu.org; Mon, 25 Dec 2023 11:58:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHoHw-00050k-FK for 67393@debbugs.gnu.org; Mon, 25 Dec 2023 11:58: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 1rHoHj-00043y-Dp; Mon, 25 Dec 2023 11:58:35 -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=eEmX2+m2tUkLXf/y7oXL5dKFjlVeCocy8zCYO+Zo64c=; b=N6PYFPKNoKXt fhAji6Rrx+IC8BUPBxwUimf75kIyyUTVNDUZyGk79cZ5DOebThP7vPOgVPT6wNwQk9FRRDQSKlI1g zDoDCOuyzteX34bVwbkEleJeE1C2YYuUg3D8gwIHf2gZoXxmmsMZjuQ1wZuEaWi/wQw3liTXh3eEZ VD1g4XIlcyESr2mUAarLhwlWhlP9/BZaI722ENeDUv5j6YMTPz0nlgd6FcSHVDY+ZyJEISIYICDPQ V6LAAWcBgqoWDXkT5DOSlNaj76cLMKvBtpkq0LDcYLihmPEU0iVQIEl2Tl02kD9KTsgNY1cS+63oa KHJgRWUVcNu2XdstwlhN5Q==; Date: Mon, 25 Dec 2023 18:58:32 +0200 Message-Id: <83jzp29q2v.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87zfxymdk6.fsf@localhost> (message from Ihor Radchenko on Mon, 25 Dec 2023 16:50:33 +0000) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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: Ihor Radchenko > Cc: juri@linkov.net, stefankangas@gmail.com, materus213@gmail.com, > 67393@debbugs.gnu.org > Date: Mon, 25 Dec 2023 16:50:33 +0000 > > Eli Zaretskii writes: > > >> Then, the "important" messages should be written in such a way that they > >> can be understood later, away from the immediate context of the message > >> trigger. > > > > I don't think I understand what this means in practice. Can you show > > what will be displayed in the mini-window in this case, and how to > > make the "important" message stand out? > > For example, the message "File exists, but cannot be read" from > `after-find-file' may be written as > > "Opening file: exists, but cannot be read" Sorry, but I don't see how this would help. "Opening file" could allude to anything; Emacs opens a lot of files all the time. A delayed message will run a high risk of missing its point, unless it presents a lot of relevant context, as a minimum the command which caused it with that command's arguments. And having said that, I'm not sure this is a good idea even if we present enough context. For starters, many messages must be acted upon immediately. > >> > How is this better than waiting for a second? > >> > >> 1. Waiting for a second creates a temptation to press C-g without > >> thinking and get the original message replaced with "Quit". > >> > >> 2. The message can be read later (not just within one second). For > >> example after a distraction in RL and being away from Emacs or a > >> short moment. > > > > Again: how will this look in practice, including the dismissal action? > > Try the following proof-of-concept code: Thanks, but this would mean a complete redesign of the Emacs messaging UI. This kind of display no longer fits the mini-window paradigm we are using, it will need a separate large enough window for showing series of messages (in which case we don't need to much wizardry to scroll through them and selectively delete them). Do we really want to make such drastic changes in our UI? From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 12:15:48 2023 Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 17:15:48 +0000 Received: from localhost ([127.0.0.1]:55247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHoYN-0001SF-MV for submit@debbugs.gnu.org; Mon, 25 Dec 2023 12:15:48 -0500 Received: from mout02.posteo.de ([185.67.36.66]:45533) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHoYJ-00018g-0x for 67393@debbugs.gnu.org; Mon, 25 Dec 2023 12:15:45 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 48076240104 for <67393@debbugs.gnu.org>; Mon, 25 Dec 2023 18:15:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703524530; bh=PI8rXjdL2W8F6nBxqTBwj0jsVnwzNQB60udNelb+j9w=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=PGTbzcEu2z6Ze8W+fN2624hDrf9ZdgUeFi5xV8xJgTYmuO6JST0WpxcWfbZUe27UX ++1jOLn1X8A1t4CAeFjXNjmrB1BFkjeQChwaqErYWfpIammll/gOynMk7tnJcxH+ay 4bp5sSa/OK9gXQ8e/Ls1vbRfL/Dp7gtYPwFlKzFcpPKSSxboiYNQLEFM75yXVJyeu8 uwHhvBDn9+nme5aDEtv4rbi+pmFu1B/qLFyRfvi9qn3QCt1P5EGQIW9//wrL658lur z2AoTjkOQ4PUe+c7jf3M+VwHelQcPkTvLC3WvKU730U2mQl0zTiv9IK6jMFDJJhplu KQ6ihyx+4pSQQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SzPg558nRz9rxD; Mon, 25 Dec 2023 18:15:29 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83jzp29q2v.fsf@gnu.org> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> <83jzp29q2v.fsf@gnu.org> Date: Mon, 25 Dec 2023 17:18:42 +0000 Message-ID: <87tto6mc99.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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 (---) Eli Zaretskii writes: >> For example, the message "File exists, but cannot be read" from >> `after-find-file' may be written as >> >> "Opening file: exists, but cannot be read" > > Sorry, but I don't see how this would help. "Opening file" could > allude to anything; Emacs opens a lot of files all the time. A > delayed message will run a high risk of missing its point, unless it > presents a lot of relevant context, as a minimum the command which > caused it with that command's arguments. Do note that I am not proposing to delay the message. It will be displayed immediately; just will not block. As for missing the point, the point is either current command opening a file - then, the context is clear; or a complex command doing many things, including opening a file - then, I doubt that blocking is very helpful. > And having said that, I'm not sure this is a good idea even if we > present enough context. For starters, many messages must be acted > upon immediately. I'd argue that messages that _must_ be acted, should not be messages. They should query user for action instead of blocking Emacs and not allowing to do anything other than C-g. >> > Again: how will this look in practice, including the dismissal action? >> >> Try the following proof-of-concept code: > > Thanks, but this would mean a complete redesign of the Emacs messaging > UI. This kind of display no longer fits the mini-window paradigm we > are using, it will need a separate large enough window for showing > series of messages (in which case we don't need to much wizardry to > scroll through them and selectively delete them). Do we really want > to make such drastic changes in our UI? I believe that such changes would be helpful. Apart from addressing the problem here, they might be useful to address the concerns about messages displayed by Elisp threads, timers, and async process callbacks. Also, if we ever get true multithreading, some way to display and separate messages coming simultaneously would be a good thing to have. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 12:35:08 2023 Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 17:35:09 +0000 Received: from localhost ([127.0.0.1]:55276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHor6-0005LH-CO for submit@debbugs.gnu.org; Mon, 25 Dec 2023 12:35:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHor4-0005Ke-Nc for 67393@debbugs.gnu.org; Mon, 25 Dec 2023 12:35: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 1rHoqr-0001R2-Vs; Mon, 25 Dec 2023 12:34:54 -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=wCYSX3hLJDwxAHXUhlqJMP6QcMMdW337rHLGH+cqq1I=; b=g0I7WL2RDbeu bHvlV8HWkYhg4odgNzyj/SzQQ2lBw6FS4DhsjiITBl2B2e5PwZk6qSHovGrth3Fu+F6LwwlZEPFB/ EE70o7hcveNlNnZ5EX/Nl6JMR7S99tAK4fTuJeo60t9irsNIyL2RRR2y+IbFNwQmUu8dlBHbMzjfi oT3nYJoQUHKMOsBX6HAVGItX0tNhMpUBVsAPp4ev3hyZVF43Gdrky2ZJeokeUittqoU9YoDSBpiCQ 1UbYpE2l/z0+xF5lmkUd6NxL8dJxioHLRR8KR5XbcV0AdlFBeMyeIlNrPjoiDaNuI1r/k4dS//aUM EIl0fQaEk5T442gc0FMA2Q==; Date: Mon, 25 Dec 2023 19:34:51 +0200 Message-Id: <83h6k69oec.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87tto6mc99.fsf@localhost> (message from Ihor Radchenko on Mon, 25 Dec 2023 17:18:42 +0000) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> <83jzp29q2v.fsf@gnu.org> <87tto6mc99.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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: Ihor Radchenko > Cc: juri@linkov.net, stefankangas@gmail.com, materus213@gmail.com, > 67393@debbugs.gnu.org > Date: Mon, 25 Dec 2023 17:18:42 +0000 > > Eli Zaretskii writes: > > > And having said that, I'm not sure this is a good idea even if we > > present enough context. For starters, many messages must be acted > > upon immediately. > > I'd argue that messages that _must_ be acted, should not be messages. > They should query user for action instead of blocking Emacs and not > allowing to do anything other than C-g. You do realize that this is contrary to everything we currently do in Emacs, right? We should the messages that must be acted upon immediately, and use sit-for to make sure the user sees the message and has an opportunity to act upon it. The message which started this discussion was just like that: it informed the user that an autosave file exists, so the user should consider using it. > > Thanks, but this would mean a complete redesign of the Emacs messaging > > UI. This kind of display no longer fits the mini-window paradigm we > > are using, it will need a separate large enough window for showing > > series of messages (in which case we don't need to much wizardry to > > scroll through them and selectively delete them). Do we really want > > to make such drastic changes in our UI? > > I believe that such changes would be helpful. Maybe so, but this will be an entirely different UX, and probably an entirely different Emacs. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 13:37:19 2023 Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 18:37:19 +0000 Received: from localhost ([127.0.0.1]:55374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHppH-0000jf-5e for submit@debbugs.gnu.org; Mon, 25 Dec 2023 13:37:19 -0500 Received: from mout02.posteo.de ([185.67.36.66]:56197) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHppC-0000jN-3B for 67393@debbugs.gnu.org; Mon, 25 Dec 2023 13:37:17 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A7F63240104 for <67393@debbugs.gnu.org>; Mon, 25 Dec 2023 19:37:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703529420; bh=xbzDCZDlJaH0UzMTrvw8M+J4EDb+QU3oJqOV6pNGNvA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ZN0Q0/s5aO9WK0obPGOb146jMDtoITHxkZ0XkUoipH4Wbwjka2GnTXoGJu9GoJUzZ lBKjhR7qBEDdNfArETj4IPnnPmrmR5ec1LMFnD5JBrLzDhQt3hZ85FsUmmXQzXUpQP iZ1VvRKpB6C+sdHEXBkC6hmb8vCPjscbfQpllMnLU2Lul97JmGr+RuQuxYOdLC9nhE FCOJ7VGmRdc8+W2a0/yvP3lUyRXgOw13852eVEEBL4Msa//VvrplWEa1t2dY8Oi3/8 NpmpPV4H0xIBZIKt1h+kNGGC4F6j+witCIKzduJjn3k55vTOdT255+a9LpIn0a6q9S AYD/pDZ1jX7gw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SzRT80Dycz9rxK; Mon, 25 Dec 2023 19:36:59 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83h6k69oec.fsf@gnu.org> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> <83jzp29q2v.fsf@gnu.org> <87tto6mc99.fsf@localhost> <83h6k69oec.fsf@gnu.org> Date: Mon, 25 Dec 2023 18:40:08 +0000 Message-ID: <87le9im8hj.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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 (---) Eli Zaretskii writes: >> I'd argue that messages that _must_ be acted, should not be messages. >> They should query user for action instead of blocking Emacs and not >> allowing to do anything other than C-g. > > You do realize that this is contrary to everything we currently do in > Emacs, right? We should the messages that must be acted upon > immediately, and use sit-for to make sure the user sees the message > and has an opportunity to act upon it. The message which started this > discussion was just like that: it informed the user that an autosave > file exists, so the user should consider using it. I disagree that sit-for gives an opportunity to act upon the message discussed in the bug report: "%s has auto save data; consider \\`M-x recover-this-file'". Consider that some command opens files one by one in sequence and one of these files has auto save data. `after-find-file' will pause that command, display the message, block Emacs (not allowing user to do anything), and then continue running the command. User has no chance to do anything about the auto save recovery until the command is finished and also has to wait extra few seconds while Emacs is blocked. (This is a real case I encountered with M-x org-agenda) In contrast, what I propose would make sure that the message is displayed for at least some period of time after the command finishes. Moreover, if multiple files have auto save data, messages about all these files will be displayed together without a need to dig into *Messages* buffer. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 14:09:00 2023 Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 19:09:00 +0000 Received: from localhost ([127.0.0.1]:55395 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHqJw-0006sv-C2 for submit@debbugs.gnu.org; Mon, 25 Dec 2023 14:09:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHqJt-0006sg-Q9 for 67393@debbugs.gnu.org; Mon, 25 Dec 2023 14:08:58 -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 1rHqJg-0000Dw-VN; Mon, 25 Dec 2023 14:08:44 -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=1ayfc2b4FpgMfL3QKKqTz7ogrJ2zd7YL8tToEy7IE1s=; b=j3MFgKcMNmUj orFf00sicBcdCLzU6aDeexgztkVm+4RPTBcnzITeWc+d6I1ar69N8OtaRHVwdDpiTsQSkCShYUjIW Lj4Im7vWqX4AdmFjoEVpG9AViXneZ4GM3IadoTMJ13EvOu8+TD8QM8omBPOpNW/IPK7CRdyfRjx1a jqhuzqR3xv2BWz32IslCx5kzkE/Lu1q9iRNUulQEaAqU6Mx9CeLt88/pOAYyq+Fp9gwfvvK7ALO3F me4cJVnZOquuFmrjZW3Pl+BXeHs11KD2ctZt/N2kaTqPKQCckxBa8M+Vp69359zS6CczijrnUUiK1 Beh4Gla1vpBYpaIEM4GR1A==; Date: Mon, 25 Dec 2023 21:08:41 +0200 Message-Id: <83edfa9k1y.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87le9im8hj.fsf@localhost> (message from Ihor Radchenko on Mon, 25 Dec 2023 18:40:08 +0000) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> <83jzp29q2v.fsf@gnu.org> <87tto6mc99.fsf@localhost> <83h6k69oec.fsf@gnu.org> <87le9im8hj.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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: Ihor Radchenko > Cc: juri@linkov.net, stefankangas@gmail.com, materus213@gmail.com, > 67393@debbugs.gnu.org > Date: Mon, 25 Dec 2023 18:40:08 +0000 > > Eli Zaretskii writes: > > > You do realize that this is contrary to everything we currently do in > > Emacs, right? We should the messages that must be acted upon > > immediately, and use sit-for to make sure the user sees the message > > and has an opportunity to act upon it. The message which started this > > discussion was just like that: it informed the user that an autosave > > file exists, so the user should consider using it. > > I disagree that sit-for gives an opportunity to act upon the message > discussed in the bug report: "%s has auto save data; consider \\`M-x > recover-this-file'". > > Consider that some command opens files one by one in sequence and one of > these files has auto save data. `after-find-file' will pause that > command, display the message, block Emacs (not allowing user to do > anything), and then continue running the command. User has no chance to > do anything about the auto save recovery until the command is finished > and also has to wait extra few seconds while Emacs is blocked. > (This is a real case I encountered with M-x org-agenda) Such a command, if it existed, should perhaps provide a better opportunity for the users, like prompt them for whether to recover from each autosave file before continuing to the next one. But I was talking about "C-x C-f", the subject of this bug report, where such a problem doesn't exist. By talking about a different command you simply change the subject, which doesn't help to make the discussion constructive. > In contrast, what I propose would make sure that the message is > displayed for at least some period of time after the command finishes. Imagine a command that needs the user to respond within a short time interval, after which the message becomes irrelevant, because the situation changed in a way that the information there is not longer pertinent. Like in those mythical Mission Impossible movies: this message will auto-destruct in 5 seconds. How will leaving all of those message on display help in that case? > Moreover, if multiple files have auto save data, messages about all > these files will be displayed together without a need to dig into > *Messages* buffer. "Dig into *Messages*" is a strange phrase to hear from a veteran Emacs user. I'd expect looking in *Messages* to be your second nature. Some users even have the habit of leaving *Messages* constantly on display -- there's your "leave messages on display" proposal already available if someone wants that. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 15:14:31 2023 Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 20:14:31 +0000 Received: from localhost ([127.0.0.1]:55433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHrLL-00027Y-7F for submit@debbugs.gnu.org; Mon, 25 Dec 2023 15:14:31 -0500 Received: from mout02.posteo.de ([185.67.36.66]:37273) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHrLI-00027H-U1 for 67393@debbugs.gnu.org; Mon, 25 Dec 2023 15:14:30 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8C348240103 for <67393@debbugs.gnu.org>; Mon, 25 Dec 2023 21:14:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703535256; bh=LXuxNznTBFGT/0ywOVbpDSp3lKttFJQT5RIb0J77Nq8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=X5JFPCMEGCvnMoHDxhGaTNyq0EOqEAiiIFUiNJ3LTjPPZgCWPpO8+evRGhfd8vEl1 Ybw9hl7KtCClA5BPsQDCcWUm1L3Cuj7Bn9/wmEA/wtCPXEjDA9etACPq4qryxBqCIy /h3DN7j7QBFxXjAbRd1Ku7RXKCQo/Hk/JUAG6+Zu8jBb5YMuUiDBk7aSCPs3yAZYiW p9y07+jLXhLHAaKabLRatgZA/8yhaKiPbUoBhobuALhKxTip59gyckrLmJbQvpZ3Hw vdLoYqGalKrZD2Ht+2fcI5zqR+qQZ6CdjiVNfAORzmYeSlprIRisAv74BmDBwWUNfP o0IAu6JhWe/0A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SzTdN0chzz6tw4; Mon, 25 Dec 2023 21:14:16 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83edfa9k1y.fsf@gnu.org> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> <83jzp29q2v.fsf@gnu.org> <87tto6mc99.fsf@localhost> <83h6k69oec.fsf@gnu.org> <87le9im8hj.fsf@localhost> <83edfa9k1y.fsf@gnu.org> Date: Mon, 25 Dec 2023 20:17:28 +0000 Message-ID: <87a5pym3zb.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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 (---) Eli Zaretskii writes: >> Consider that some command opens files one by one in sequence and one of >> these files has auto save data. `after-find-file' will pause that >> command, display the message, block Emacs (not allowing user to do >> anything), and then continue running the command. User has no chance to >> do anything about the auto save recovery until the command is finished >> and also has to wait extra few seconds while Emacs is blocked. >> (This is a real case I encountered with M-x org-agenda) > > Such a command, if it existed, should perhaps provide a better > opportunity for the users, like prompt them for whether to recover > from each autosave file before continuing to the next one. May you please elaborate how a command calling of `find-file' or similar can provide such prompt? > But I was talking about "C-x C-f", the subject of this bug report, > where such a problem doesn't exist. By talking about a different > command you simply change the subject, which doesn't help to make the > discussion constructive. Fair. My reply was more to (when (and warn msg) (message "%s" msg) (or not-serious (sit-for 1 t)))) ^^^^^^^^^^^^^ rather than to the original bug report. But I am not sure if it is worth it to open a brand-new bug report about `find-file' used from complex commands. >> In contrast, what I propose would make sure that the message is >> displayed for at least some period of time after the command finishes. > > Imagine a command that needs the user to respond within a short time > interval, after which the message becomes irrelevant, because the > situation changed in a way that the information there is not longer > pertinent. Like in those mythical Mission Impossible movies: this > message will auto-destruct in 5 seconds. How will leaving all of > those message on display help in that case? I consider such situation worth a full interactive prompt, not limited to 5 seconds. For example, C-x C-f could prompt about recovering from backup file, if such file is detected. >> Moreover, if multiple files have auto save data, messages about all >> these files will be displayed together without a need to dig into >> *Messages* buffer. > > "Dig into *Messages*" is a strange phrase to hear from a veteran Emacs > user. I'd expect looking in *Messages* to be your second nature. It is not. > Some users even have the habit of leaving *Messages* constantly on > display -- there's your "leave messages on display" proposal already > available if someone wants that. After `set-multi-message' became a thing, I no longer need to consult *Messages* often. `set-multi-message' was really an eye-opener on how much useful information I miss when messages are coming in quick succession. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 27 07:34:28 2023 Received: (at 67393) by debbugs.gnu.org; 27 Dec 2023 12:34:28 +0000 Received: from localhost ([127.0.0.1]:35477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIT7E-0004f5-7A for submit@debbugs.gnu.org; Wed, 27 Dec 2023 07:34:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIT7B-0004er-BF for 67393@debbugs.gnu.org; Wed, 27 Dec 2023 07:34:26 -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 1rIT75-0000F3-4D; Wed, 27 Dec 2023 07:34:19 -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=SApVzia/Z618dudE/vjCxOjgqMY7KX3CdkV1vBPHc2M=; b=rJ6PRvHqrQ97 22aVu456/7J76fCH50g4jq2yVWKqNQraRuSrF7qnb7SdH/FQJvUBJWukZeaMbD7cIxo3CrPnsHV3V GdMOb3J3BLZ3d7jdjaOuns6GgATAvpB9Ux8nIlZXl+Kv7mz3k8f+pFPkp4fRwkvUbuTbtgy1j2QQx IfPnBvZEb9+D03PxBTm7vcZOibBoFsk9hc+RNoW5rQG7+PcC9FEicBS4ujjBlt9i8a/3ypcVETL3D 2PFKBMtp5drElbvG9Tly7U2Bi1u1RydpwDkoS7fbWHDkErACLSaee/VJNuN3gq4P6pndSdkcBxNJh Q8Ga58dbgwYGtaDzekqA8Q==; Date: Wed, 27 Dec 2023 14:34:01 +0200 Message-Id: <83wmsz964m.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87a5pym3zb.fsf@localhost> (message from Ihor Radchenko on Mon, 25 Dec 2023 20:17:28 +0000) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> <83jzp29q2v.fsf@gnu.org> <87tto6mc99.fsf@localhost> <83h6k69oec.fsf@gnu.org> <87le9im8hj.fsf@localhost> <83edfa9k1y.fsf@gnu.org> <87a5pym3zb.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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: Ihor Radchenko > Cc: juri@linkov.net, stefankangas@gmail.com, materus213@gmail.com, > 67393@debbugs.gnu.org > Date: Mon, 25 Dec 2023 20:17:28 +0000 > > Eli Zaretskii writes: > > >> Consider that some command opens files one by one in sequence and one of > >> these files has auto save data. `after-find-file' will pause that > >> command, display the message, block Emacs (not allowing user to do > >> anything), and then continue running the command. User has no chance to > >> do anything about the auto save recovery until the command is finished > >> and also has to wait extra few seconds while Emacs is blocked. > >> (This is a real case I encountered with M-x org-agenda) > > > > Such a command, if it existed, should perhaps provide a better > > opportunity for the users, like prompt them for whether to recover > > from each autosave file before continuing to the next one. > > May you please elaborate how a command calling of `find-file' or similar > can provide such prompt? I'm not sure I understand what you mean, because the answer seems too obvious: just prompt after opening each file that has autosave data. But that's probably not what you had in mind. > >> In contrast, what I propose would make sure that the message is > >> displayed for at least some period of time after the command finishes. > > > > Imagine a command that needs the user to respond within a short time > > interval, after which the message becomes irrelevant, because the > > situation changed in a way that the information there is not longer > > pertinent. Like in those mythical Mission Impossible movies: this > > message will auto-destruct in 5 seconds. How will leaving all of > > those message on display help in that case? > > I consider such situation worth a full interactive prompt, not limited > to 5 seconds. > > For example, C-x C-f could prompt about recovering from backup file, if > such file is detected. Yes. My point being that just a fire-and-forget message is not good in these cases anyway, so the issue we are discussing doesn't have to cater to such cases. > >> Moreover, if multiple files have auto save data, messages about all > >> these files will be displayed together without a need to dig into > >> *Messages* buffer. > > > > "Dig into *Messages*" is a strange phrase to hear from a veteran Emacs > > user. I'd expect looking in *Messages* to be your second nature. > > It is not. > > > Some users even have the habit of leaving *Messages* constantly on > > display -- there's your "leave messages on display" proposal already > > available if someone wants that. > > After `set-multi-message' became a thing, I no longer need to consult > *Messages* often. `set-multi-message' was really an eye-opener on how > much useful information I miss when messages are coming in quick > succession. To each their own. I think set-multi-message has its uses, but I don't think it can solve all of the cases, in particular those where we need to attract the users' attention to a particularly important message. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 27 12:24:06 2023 Received: (at 67393) by debbugs.gnu.org; 27 Dec 2023 17:24:06 +0000 Received: from localhost ([127.0.0.1]:37697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIXdW-0003LF-1k for submit@debbugs.gnu.org; Wed, 27 Dec 2023 12:24:06 -0500 Received: from relay2-d.mail.gandi.net ([2001:4b98:dc4:8::222]:54903) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIXdV-0003Kl-0G for 67393@debbugs.gnu.org; Wed, 27 Dec 2023 12:24:05 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id CA6E340005; Wed, 27 Dec 2023 17:23:58 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83r0jbbg2z.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 24 Dec 2023 20:39:16 +0200") Organization: LINKOV.NET References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> Date: Wed, 27 Dec 2023 19:20:07 +0200 Message-ID: <86a5pv508o.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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.7 (-) >> > What I meant is to change the default `set-message-function' in such a >> > way that it displays "important" messages for a custom time period, in >> > addition to the last message. >> >> I agree. The most annoying delay is in 'ispell-parse-output': >> >> (ding) ; error message from ispell! >> (message "Ispell error: %s" output) >> (sit-for 5) >> >> So I need to waste 5 seconds several times during spell-checking. > > Only when there's an error, right? Often during spell-checking it's really not an error, but a warning that text in some unsupported encoding can't be spell-checked. >> It would be nicer to prepend this error message to any last displayed >> message during these 5 seconds. > > We don't really know whether doing that will be effective. Given N > lines of messages in the echo-area, what are the chances that the user > will see all of them, or even the most important one(s)? > > IOW, we don't have any real experience with this kind of UI. We need > to collect such experience first, before we conclude that this could > be used as an alternative to sit-for. I propose to refactor such code (message "Ispell error: %s" output) (sit-for 5) to a new separate function, e.g. (important-message 5 "Ispell error: %s" output) with a simple implementation (defun important-message (seconds format-string &rest args) (apply #'message format-string args) (sit-for seconds)) Then users could easily override such annoying delay. Or maybe even the default implementation can check if set-message-functions already contains set-multi-message that ensures that the important message will not be missed, and not to use sit-for in this case. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 27 12:33:55 2023 Received: (at 67393) by debbugs.gnu.org; 27 Dec 2023 17:33:56 +0000 Received: from localhost ([127.0.0.1]:37717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIXn1-0006Fj-HE for submit@debbugs.gnu.org; Wed, 27 Dec 2023 12:33:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIXmz-0006FR-2l for 67393@debbugs.gnu.org; Wed, 27 Dec 2023 12:33:54 -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 1rIXmu-0004vx-DK; Wed, 27 Dec 2023 12:33:48 -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=QA1qFf6s4D55NhWyGjRDJ2h65iICZFVqDQATBr7ULxI=; b=I0YJug4g7Fpd QEZ5zZEPLkZx99rPJFhjByMfZ6hDxyxVqKW4PXHHqVJyNDDQQ4qErbSSyH1CR2uqpjebvD2iNo5ua 8uaMYJIpAsTXACet92Dze+E8FTVqXNy1UJwSqIe9hQHuTbDN35oBU5WL0ruKjdpB4RSGy8imKoWQE PmCV+ZruozwPui5yh3+9LvdLUESDfi7ze2Sb+1NMa/xuMjsKEiAgl01au3PAe/xn75g5wmH5J/EkG VKfiQ2rT48HXR38eipbVVZFx+bgw/fDiARtRI+Orvm5FS9hBiMk6g1OLsa/+uVkZXvm0uDNX3fQf7 75urSy8SqI7Hui+oXJYI0w==; Date: Wed, 27 Dec 2023 19:33:31 +0200 Message-Id: <83h6k38s9g.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86a5pv508o.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 27 Dec 2023 19:20:07 +0200) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <86a5pv508o.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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: Juri Linkov > Cc: yantar92@posteo.net, stefankangas@gmail.com, materus213@gmail.com, > 67393@debbugs.gnu.org > Date: Wed, 27 Dec 2023 19:20:07 +0200 > > >> (ding) ; error message from ispell! > >> (message "Ispell error: %s" output) > >> (sit-for 5) > >> > >> So I need to waste 5 seconds several times during spell-checking. > > > > Only when there's an error, right? > > Often during spell-checking it's really not an error, but a warning > that text in some unsupported encoding can't be spell-checked. "Unsupported encoding"? Last time I saw this was when I was using ispell as the speller. Since I switched to Hunspell years ago, these problems are gone for good, since Hunspell uses UTF-8. How come you still see this? > I propose to refactor such code > > (message "Ispell error: %s" output) > (sit-for 5) > > to a new separate function, e.g. > > (important-message 5 "Ispell error: %s" output) > > with a simple implementation > > (defun important-message (seconds format-string &rest args) > (apply #'message format-string args) > (sit-for seconds)) > > Then users could easily override such annoying delay. > Or maybe even the default implementation can check > if set-message-functions already contains set-multi-message > that ensures that the important message will not be missed, > and not to use sit-for in this case. I don't mind much, but is this really the best we can do? Asking users to customize Emacs by overriding functions is not very friendly, and in this case we certainly could do better, for example by making 5 be a defcustom. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 02:58:41 2023 Received: (at 67393) by debbugs.gnu.org; 28 Dec 2023 07:58:42 +0000 Received: from localhost ([127.0.0.1]:38342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIlHt-0001cr-Id for submit@debbugs.gnu.org; Thu, 28 Dec 2023 02:58:41 -0500 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:46519) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIlHq-0001cc-Uz for 67393@debbugs.gnu.org; Thu, 28 Dec 2023 02:58:39 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 046971BF206; Thu, 28 Dec 2023 07:58:31 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83h6k38s9g.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 27 Dec 2023 19:33:31 +0200") Organization: LINKOV.NET References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <86a5pv508o.fsf@mail.linkov.net> <83h6k38s9g.fsf@gnu.org> Date: Thu, 28 Dec 2023 09:57:01 +0200 Message-ID: <86bkaa7oaa.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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.7 (-) >> >> (ding) ; error message from ispell! >> >> (message "Ispell error: %s" output) >> >> (sit-for 5) >> >> >> >> So I need to waste 5 seconds several times during spell-checking. >> > >> > Only when there's an error, right? >> >> Often during spell-checking it's really not an error, but a warning >> that text in some unsupported encoding can't be spell-checked. > > "Unsupported encoding"? Last time I saw this was when I was using > ispell as the speller. Since I switched to Hunspell years ago, these > problems are gone for good, since Hunspell uses UTF-8. How come you > still see this? This happens occasionally with Hunspell, but I can't explain why, maybe due to misconfiguration. I could debug this later. >> I propose to refactor such code >> >> (message "Ispell error: %s" output) >> (sit-for 5) >> >> to a new separate function, e.g. >> >> (important-message 5 "Ispell error: %s" output) >> >> with a simple implementation >> >> (defun important-message (seconds format-string &rest args) >> (apply #'message format-string args) >> (sit-for seconds)) >> >> Then users could easily override such annoying delay. >> Or maybe even the default implementation can check >> if set-message-functions already contains set-multi-message >> that ensures that the important message will not be missed, >> and not to use sit-for in this case. > > I don't mind much, but is this really the best we can do? This is just the first thing that we could do. So the first task is to find all such places, and replace them with the single function call. > Asking users to customize Emacs by overriding functions is not very > friendly, and in this case we certainly could do better, for example > by making 5 be a defcustom. A defcustom would be one option. 'set-important-message' like implemented by Ihor would be another option. All this could be added after creating the new function 'important-message'. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 08:56:47 2023 Received: (at 67393) by debbugs.gnu.org; 28 Dec 2023 13:56:47 +0000 Received: from localhost ([127.0.0.1]:38741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIqsQ-0006bD-R2 for submit@debbugs.gnu.org; Thu, 28 Dec 2023 08:56:47 -0500 Received: from mout01.posteo.de ([185.67.36.65]:54013) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIqsN-0006ax-G7 for 67393@debbugs.gnu.org; Thu, 28 Dec 2023 08:56:45 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 12DB224002B for <67393@debbugs.gnu.org>; Thu, 28 Dec 2023 14:56:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703771798; bh=HxxbBuwLsu50gruaQn7jnsWRJmuEYsqEDIRHiyoqGXI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ZAuhCxVR2CYlKu+CC8RTqAiHnJ9KOt2Owgd4d7AEvaoAFnhMHaCBZ/2JByQvTGeLA qAe5+Lf0MVDA8pPKYN18uvjIw5aYqVkDfF6weFGNaMQtheIQIJKlicBMvHPoy10WiF +IqUFum1+6I+0WbSWFiQkYuCOWyARNcFf00lifg4Jt0Tbm2pqYkUbCKiuww/sULmAz obxkxS+8zMxAi73/pVxAFbw9lu1YfwL7RJBR3CyDIUS2qL7BL0yuIFY8yyDVbjZpCs FQAzzfMUiY1lQYyEl3kRNAC/9ntdZMbPKiAhIdoBpqiWyP3DfOUHkXpgSsp5hWYQ2J EciqRr71wiOfQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4T196F2XSCz6tm4; Thu, 28 Dec 2023 14:56:37 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83wmsz964m.fsf@gnu.org> References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <87mstz1l0b.fsf@localhost> <83bkafbdto.fsf@gnu.org> <87bkaf1iux.fsf@localhost> <83a5pzbbg7.fsf@gnu.org> <87zfxymdk6.fsf@localhost> <83jzp29q2v.fsf@gnu.org> <87tto6mc99.fsf@localhost> <83h6k69oec.fsf@gnu.org> <87le9im8hj.fsf@localhost> <83edfa9k1y.fsf@gnu.org> <87a5pym3zb.fsf@localhost> <83wmsz964m.fsf@gnu.org> Date: Thu, 28 Dec 2023 13:59:49 +0000 Message-ID: <875y0iwhpm.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net 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 (---) Eli Zaretskii writes: >> > Such a command, if it existed, should perhaps provide a better >> > opportunity for the users, like prompt them for whether to recover >> > from each autosave file before continuing to the next one. >> >> May you please elaborate how a command calling of `find-file' or similar >> can provide such prompt? > > I'm not sure I understand what you mean, because the answer seems too > obvious: just prompt after opening each file that has autosave data. > But that's probably not what you had in mind. It is actually what I had in mind, but I am concerned about several possible caveats: 1. Introducing a query where there was none previously may break noninteractive Emacs and existing code that makes an assumption about `find-file' not querying user in most cases. 2. autosave data is just one of several cases when `after-find-file' uses `sit-for': - "File exists, but cannot be read" - "Symbolic link that points to nonexistent file" - "%s has auto save data; consider \\`M-x recover-this-file'" - "File not found and directory write-protected" - "Use M-x make-directory RET RET to create the directory and its parents" It is not clear if all of these cases should ask user immediately and wait for an answer or just some of them. And if just some of them, whether to leave the `sit-for' delay after displaying message or not. >> After `set-multi-message' became a thing, I no longer need to consult >> *Messages* often. `set-multi-message' was really an eye-opener on how >> much useful information I miss when messages are coming in quick >> succession. > > To each their own. I think set-multi-message has its uses, but I > don't think it can solve all of the cases, in particular those where > we need to attract the users' attention to a particularly important > message. We are in agreement here. I also do not think that set-multi-message should be used everywhere. However, I do think that using `sit-for' to attract attention is not a good idea and such approach should be replaced either with explicit user prompt or, when the message is not as important, with something that does not block Emacs (like my proposal or something else we can come up with). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 11:43:11 2024 Received: (at 67393) by debbugs.gnu.org; 16 Jan 2024 16:43:11 +0000 Received: from localhost ([127.0.0.1]:49565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPmWt-0000j4-16 for submit@debbugs.gnu.org; Tue, 16 Jan 2024 11:43:11 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:34517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPmWr-0000ic-0j for 67393@debbugs.gnu.org; Tue, 16 Jan 2024 11:43:09 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id EE7DD60011; Tue, 16 Jan 2024 16:43:00 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <86bkaa7oaa.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 28 Dec 2023 09:57:01 +0200") Organization: LINKOV.NET References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <86a5pv508o.fsf@mail.linkov.net> <83h6k38s9g.fsf@gnu.org> <86bkaa7oaa.fsf@mail.linkov.net> Date: Tue, 16 Jan 2024 18:36:51 +0200 Message-ID: <868r4pp74s.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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.7 (-) --=-=-= Content-Type: text/plain >>> I propose to refactor such code >>> >>> (message "Ispell error: %s" output) >>> (sit-for 5) >>> >>> to a new separate function, e.g. >>> >>> (important-message 5 "Ispell error: %s" output) >>> >>> with a simple implementation >>> >>> (defun important-message (seconds format-string &rest args) >>> (apply #'message format-string args) >>> (sit-for seconds)) >>> >>> Then users could easily override such annoying delay. >>> Or maybe even the default implementation can check >>> if set-message-functions already contains set-multi-message >>> that ensures that the important message will not be missed, >>> and not to use sit-for in this case. >> >> I don't mind much, but is this really the best we can do? > > This is just the first thing that we could do. > So the first task is to find all such places, > and replace them with the single function call. > >> Asking users to customize Emacs by overriding functions is not very >> friendly, and in this case we certainly could do better, for example >> by making 5 be a defcustom. > > A defcustom would be one option. 'set-important-message' like > implemented by Ihor would be another option. All this could be > added after creating the new function 'important-message'. So here is the new function 'important-message' and its calls in two discussed places. I'm not sure why 'after-find-file' uses non-nil NODISP arg in (sit-for 1 t). This means is that the message is not displayed? Then why 'message' is called? I'm asking this because if NODISP is unnecessary then the signature of 'important-message' without NODISP will be shorter and more nice to use. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=important-message.patch diff --git a/lisp/files.el b/lisp/files.el index 9c8914bfc50..b22bf4a14c6 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -2781,8 +2781,9 @@ after-find-file (unless (file-directory-p default-directory) "Use M-x make-directory RET RET to create the directory and its parents"))))) (when (and warn msg) - (message "%s" msg) - (or not-serious (sit-for 1 t)))) + (if not-serious + (message "%s" msg) + (important-message 1 t "%s" msg)))) (when (and auto-save-default (not noauto)) (auto-save-mode 1))) ;; Make people do a little extra work (C-x C-q) diff --git a/lisp/simple.el b/lisp/simple.el index 692c0dacefc..6fa74bde037 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -4794,6 +4794,12 @@ max-mini-window-lines ((integerp max-mini-window-height) max-mini-window-height) (t 1))) +(defun important-message (seconds nodisp format-string &rest args) + "Display an important MESSAGE in the echo area. +Make sure that MESSAGE stays displayed for the specified number of SECONDS." + (apply #'message format-string args) + (sit-for seconds nodisp)) + (defun display-message-or-buffer (message &optional buffer-name action frame) "Display MESSAGE in the echo area if possible, otherwise in a pop-up buffer. MESSAGE may be either a string or a buffer. diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el index 17af1f1d926..3c9eda47cbd 100644 --- a/lisp/textmodes/ispell.el +++ b/lisp/textmodes/ispell.el @@ -2768,8 +2768,7 @@ ispell-parse-output (substring output 2)) ; return root word ((equal 0 (string-match "[\ra-zA-Z]" output)) (ding) ; error message from ispell! - (message "Ispell error: %s" output) - (sit-for 5) + (important-message 5 nil "Ispell error: %s" output) nil) (t ; need to process &, ?, and #'s (let ((type (aref output 0)) ; &, ?, or # --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 12:11:06 2024 Received: (at 67393) by debbugs.gnu.org; 16 Jan 2024 17:11:06 +0000 Received: from localhost ([127.0.0.1]:49622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPmxu-0006sx-Bg for submit@debbugs.gnu.org; Tue, 16 Jan 2024 12:11:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPmxs-0006s3-Kj for 67393@debbugs.gnu.org; Tue, 16 Jan 2024 12:11:05 -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 1rPmxl-0002P2-Ti; Tue, 16 Jan 2024 12:10:57 -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=SCytJTU8cAzJBWZbp/nftrGhRJSPEI9uulKy6vCXkwQ=; b=Hn912sgwCL1/ VTTSGCNU9Ws4j91q84KaL2l/haUpdPqOdn6sWJmj1k8ZcboZJIHFocvDjXR55AyIqen92p/nWl9Q2 gptBBf9piL2NNjc5oSXA9Nts4I2afpo8zrYW2RbVON/Hk4DfZFDVDUVQUdyVKZeJTKDSo51qYblFe X4lSeDInC7Kiub+fs4+n/cQ6dLtjdJM720QGHK8Co5aJWds1tz09MIZTmgKRYQOaFYGmSrmrCEpas P5Pk9RE59hO94QWddPyEDCGHxPModJ7zggGl5a3AVAeccyv2P3sffI5BgJH+ICscAJIdKRNGqYb2b 6yhNdwDEsABASCRRLuHKUw==; Date: Tue, 16 Jan 2024 19:10:46 +0200 Message-Id: <83zfx5b3vt.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <868r4pp74s.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 16 Jan 2024 18:36:51 +0200) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <86a5pv508o.fsf@mail.linkov.net> <83h6k38s9g.fsf@gnu.org> <86bkaa7oaa.fsf@mail.linkov.net> <868r4pp74s.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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: Juri Linkov > Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, > stefankangas@gmail.com > Date: Tue, 16 Jan 2024 18:36:51 +0200 > > > A defcustom would be one option. 'set-important-message' like > > implemented by Ihor would be another option. All this could be > > added after creating the new function 'important-message'. > > So here is the new function 'important-message' and its calls > in two discussed places. Is this in preparation for some followup? Because if not, I'm not sure it is justified to add a short function that has just 2 callers. What do we gain, as a counter-weight to the need to document the new function, insist that new code uses it, etc.? What do others think? > I'm not sure why 'after-find-file' uses non-nil NODISP arg > in (sit-for 1 t). This means is that the message is not > displayed? Then why 'message' is called? I think it means redisplay is not called. 'message' causes redisplay of the echo-area, but we don't need to redisplay the rest. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 12:48:55 2024 Received: (at 67393) by debbugs.gnu.org; 16 Jan 2024 17:48:55 +0000 Received: from localhost ([127.0.0.1]:49710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPnYV-0007U1-EW for submit@debbugs.gnu.org; Tue, 16 Jan 2024 12:48:55 -0500 Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]:54189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPnYS-0007TL-Vd for 67393@debbugs.gnu.org; Tue, 16 Jan 2024 12:48:53 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 9E69FE0003; Tue, 16 Jan 2024 17:48:44 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83zfx5b3vt.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Jan 2024 19:10:46 +0200") Organization: LINKOV.NET References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <86a5pv508o.fsf@mail.linkov.net> <83h6k38s9g.fsf@gnu.org> <86bkaa7oaa.fsf@mail.linkov.net> <868r4pp74s.fsf@mail.linkov.net> <83zfx5b3vt.fsf@gnu.org> Date: Tue, 16 Jan 2024 19:43:09 +0200 Message-ID: <865xztnphu.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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.7 (-) >> > A defcustom would be one option. 'set-important-message' like >> > implemented by Ihor would be another option. All this could be >> > added after creating the new function 'important-message'. >> >> So here is the new function 'important-message' and its calls >> in two discussed places. > > Is this in preparation for some followup? Because if not, I'm not > sure it is justified to add a short function that has just 2 callers. > What do we gain, as a counter-weight to the need to document the new > function, insist that new code uses it, etc.? Indeed, these 2 test cases are for preparation to using it everywhere. >> I'm not sure why 'after-find-file' uses non-nil NODISP arg >> in (sit-for 1 t). This means is that the message is not >> displayed? Then why 'message' is called? > > I think it means redisplay is not called. 'message' causes redisplay > of the echo-area, but we don't need to redisplay the rest. Would it be safe to drop NODISP in the new function? I see that most calls of 'message' with 'sit-for' don't use the NODISP arg. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 13:52:11 2024 Received: (at 67393) by debbugs.gnu.org; 16 Jan 2024 18:52:11 +0000 Received: from localhost ([127.0.0.1]:49760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPoXj-0002wo-G2 for submit@debbugs.gnu.org; Tue, 16 Jan 2024 13:52:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPoXg-0002wb-Kl for 67393@debbugs.gnu.org; Tue, 16 Jan 2024 13:52:09 -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 1rPoXY-0002gY-RU; Tue, 16 Jan 2024 13:52: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=QdYlW28rwvHXO4uYygFKN7XeW15bd8RdkdTlTMI8CzY=; b=CXzhQfpGTCWF H/OMx2cGzMEHKVuN925SX0FcOKd3Yb8dwrMBu+lfuT3hRzVD2Q7x/C+TOTBtkn/YnKr8Mr0oBPnOQ AMSrrgmljgzxBVmDzquJnSLFXOe/s2j2a6LdI+UXW9NtYvDFlvMtj8+jwG7kBRCXl1dHBXT0SqznU baF2LrpwxqIhtLyW5k4hXh0Wy8ZNPjpq+s/ZK0R3UMg1J67IhfH0cm8SoYDHU2xPBTBsxxN1/Li26 seWGq470IWli+NsabG0134gAuwgVdvR8is8RB/RPLgSijIDXGC1jlgMIwXgajQq0lkI8C/oepIjT2 n445JGnF9AdnaBtBqGol7w==; Date: Tue, 16 Jan 2024 20:51:49 +0200 Message-Id: <83y1cpaz7e.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <865xztnphu.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 16 Jan 2024 19:43:09 +0200) Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <86a5pv508o.fsf@mail.linkov.net> <83h6k38s9g.fsf@gnu.org> <86bkaa7oaa.fsf@mail.linkov.net> <868r4pp74s.fsf@mail.linkov.net> <83zfx5b3vt.fsf@gnu.org> <865xztnphu.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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: Juri Linkov > Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, > stefankangas@gmail.com > Date: Tue, 16 Jan 2024 19:43:09 +0200 > > >> > A defcustom would be one option. 'set-important-message' like > >> > implemented by Ihor would be another option. All this could be > >> > added after creating the new function 'important-message'. > >> > >> So here is the new function 'important-message' and its calls > >> in two discussed places. > > > > Is this in preparation for some followup? Because if not, I'm not > > sure it is justified to add a short function that has just 2 callers. > > What do we gain, as a counter-weight to the need to document the new > > function, insist that new code uses it, etc.? > > Indeed, these 2 test cases are for preparation to using it everywhere. Then I think we should consider all of those changes together. > >> I'm not sure why 'after-find-file' uses non-nil NODISP arg > >> in (sit-for 1 t). This means is that the message is not > >> displayed? Then why 'message' is called? > > > > I think it means redisplay is not called. 'message' causes redisplay > > of the echo-area, but we don't need to redisplay the rest. > > Would it be safe to drop NODISP in the new function? > I see that most calls of 'message' with 'sit-for' > don't use the NODISP arg. I don't see a need to remove it, as one caller that uses it is enough to justify it, and the price is hardly significant. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 17 11:50:09 2024 Received: (at 67393) by debbugs.gnu.org; 17 Jan 2024 16:50:09 +0000 Received: from localhost ([127.0.0.1]:53162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ979-0006UV-OM for submit@debbugs.gnu.org; Wed, 17 Jan 2024 11:50:09 -0500 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:39741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ976-0006Tp-34 for 67393@debbugs.gnu.org; Wed, 17 Jan 2024 11:50:05 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 4983A1C0002; Wed, 17 Jan 2024 16:49:54 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#67393: 29.1; Slow to open file if autosave exists In-Reply-To: <83y1cpaz7e.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Jan 2024 20:51:49 +0200") Organization: LINKOV.NET References: <83a5r5gdxk.fsf@gnu.org> <87frztc7iy.fsf@localhost> <867cl4kg4l.fsf@mail.linkov.net> <87cyuwdcb4.fsf@localhost> <868r5jse0m.fsf@mail.linkov.net> <83r0jbbg2z.fsf@gnu.org> <86a5pv508o.fsf@mail.linkov.net> <83h6k38s9g.fsf@gnu.org> <86bkaa7oaa.fsf@mail.linkov.net> <868r4pp74s.fsf@mail.linkov.net> <83zfx5b3vt.fsf@gnu.org> <865xztnphu.fsf@mail.linkov.net> <83y1cpaz7e.fsf@gnu.org> Date: Wed, 17 Jan 2024 18:48:57 +0200 Message-ID: <86y1cn29dy.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67393 Cc: materus213@gmail.com, yantar92@posteo.net, 67393@debbugs.gnu.org, stefankangas@gmail.com 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.7 (-) --=-=-= Content-Type: text/plain > Then I think we should consider all of those changes together. Ok, here is a complete patch. >> Would it be safe to drop NODISP in the new function? >> I see that most calls of 'message' with 'sit-for' >> don't use the NODISP arg. > > I don't see a need to remove it, as one caller that uses it is enough > to justify it, and the price is hardly significant. The problem is that in most calls the argument NODISP is nil. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=important-message.patch diff --git a/etc/NEWS b/etc/NEWS index 939caed14f6..0754645bdc8 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1777,6 +1777,8 @@ The declaration '(important-return-value t)' sets the 'important-return-value' property which indicates that the function return value should probably not be thrown away implicitly. +** New function 'important-message' to display messages with a delay. + +++ ** New functions 'file-user-uid' and 'file-group-gid'. These functions are like 'user-uid' and 'group-gid', respectively, but diff --git a/lisp/allout.el b/lisp/allout.el index 95b73c54934..b00e256aaf1 100644 --- a/lisp/allout.el +++ b/lisp/allout.el @@ -1519,7 +1519,7 @@ allout-write-contents-hook-handler " %s") (buffer-name (current-buffer)) failure))) - (message text)(sit-for 2) + (important-message 2 nil text) text))))) )) ;;;_ > allout-after-saves-handler () @@ -1957,8 +1957,7 @@ allout-mode (buffer-name))) ;; Problem applying exposure -- notify user, but don't ;; interrupt, eg, file visit: - (error (message "%s" (car (cdr err))) - (sit-for 1)))) + (error (important-message 1 nil "%s" (car (cdr err)))))) ) ; when allout-layout ) ; if (allout-mode-p) ) ; let (()) diff --git a/lisp/desktop.el b/lisp/desktop.el index ff113c85e12..3587636271a 100644 --- a/lisp/desktop.el +++ b/lisp/desktop.el @@ -1373,8 +1373,8 @@ desktop-read (unless (eq (emacs-pid) owner) (condition-case nil (desktop-claim-lock) - (file-error (message "Couldn't record use of desktop file") - (sit-for 1)))) + (file-error (important-message + 1 nil "Couldn't record use of desktop file")))) (unless (desktop-restoring-frameset-p) ;; `desktop-create-buffer' puts buffers at end of the buffer list. @@ -1736,8 +1736,7 @@ desktop-idle-create-buffers (unless desktop-buffer-args-list (cancel-timer desktop-lazy-timer) (setq desktop-lazy-timer nil) - (message "Lazy desktop load complete") - (sit-for 3) + (important-message 3 nil "Lazy desktop load complete") (message ""))))) (defun desktop-lazy-complete () diff --git a/lisp/ebuff-menu.el b/lisp/ebuff-menu.el index 743b92578eb..86b5ce9367f 100644 --- a/lisp/ebuff-menu.el +++ b/lisp/ebuff-menu.el @@ -256,8 +256,7 @@ Electric-buffer-menu-mode-view-buffer (if bufnam (view-buffer bufnam) (ding) - (message "Buffer %s does not exist!" bufnam) - (sit-for 4)))) + (important-message 4 nil "Buffer %s does not exist!" bufnam)))) (defvar electric-buffer-overlay nil) diff --git a/lisp/electric.el b/lisp/electric.el index fee0bf36d7f..20327ed48f6 100644 --- a/lisp/electric.el +++ b/lisp/electric.el @@ -105,26 +105,22 @@ Electric-command-loop (buffer-read-only (if loop-function (setq err conditions) (ding) - (message "Buffer is read-only") - (sit-for 2))) + (important-message 2 nil "Buffer is read-only"))) (beginning-of-buffer (if loop-function (setq err conditions) (ding) - (message "Beginning of Buffer") - (sit-for 2))) + (important-message 2 nil "Beginning of Buffer"))) (end-of-buffer (if loop-function (setq err conditions) (ding) - (message "End of Buffer") - (sit-for 2))) + (important-message 2 nil "End of Buffer"))) (error (if loop-function (setq err conditions) (ding) - (message "Error: %s" + (important-message 2 nil "Error: %s" (if (eq (car conditions) 'error) (car (cdr conditions)) - (prin1-to-string conditions))) - (sit-for 2)))) + (prin1-to-string conditions)))))) (ding)) (if loop-function (funcall loop-function loop-state err)))) (ding) diff --git a/lisp/files.el b/lisp/files.el index 9c8914bfc50..f402dddf1c6 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -2781,8 +2781,9 @@ after-find-file (unless (file-directory-p default-directory) "Use M-x make-directory RET RET to create the directory and its parents"))))) (when (and warn msg) - (message "%s" msg) - (or not-serious (sit-for 1 t)))) + (if not-serious + (message "%s" msg) + (important-message 1 t "%s" msg)))) (when (and auto-save-default (not noauto)) (auto-save-mode 1))) ;; Make people do a little extra work (C-x C-q) diff --git a/lisp/ido.el b/lisp/ido.el index 6e51dc67196..0e7934da59d 100644 --- a/lisp/ido.el +++ b/lisp/ido.el @@ -2015,8 +2015,7 @@ ido-read-internal (condition-case nil (progn (make-directory d t) t) (error - (message "Could not create directory") - (sit-for 1) + (important-message 1 nil "Could not create directory") nil)))) (progn (ido-set-current-directory d nil (eq ido-exit 'chdir)) diff --git a/lisp/info-look.el b/lisp/info-look.el index da7beafe500..8d79837fa2e 100644 --- a/lisp/info-look.el +++ b/lisp/info-look.el @@ -457,8 +457,7 @@ info-lookup (Info-goto-node node) (setq doc-found t))) (error - (message "Cannot access Info node %s" node) - (sit-for 1) + (important-message 1 nil "Cannot access Info node %s" node) nil)) (condition-case nil (progn @@ -569,8 +568,7 @@ info-lookup-make-completions (Info-goto-node node) (setq doc-found t)) (error - (message "Cannot access Info node `%s'" node) - (sit-for 1) + (important-message 1 nil "Cannot access Info node `%s'" node) nil)) (condition-case nil (progn diff --git a/lisp/info.el b/lisp/info.el index e56344825b9..b35e4edcaa3 100644 --- a/lisp/info.el +++ b/lisp/info.el @@ -3742,9 +3742,9 @@ Info-apropos-matches (setq nodes (cdr nodes) node (car nodes))) (Info-goto-node node)))) (error - (message "%s" (if (eq (car-safe err) 'error) - (nth 1 err) err)) - (sit-for 1 t))))) + (important-message + 1 t "%s" (if (eq (car-safe err) 'error) + (nth 1 err) err)))))) (Info-find-node current-file current-node) (setq Info-history ohist Info-history-list ohist-list) diff --git a/lisp/isearch.el b/lisp/isearch.el index 4cac79a3f4a..b7c774f08f4 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -2138,12 +2138,12 @@ isearch--momentary-message "Print STRING at the end of the isearch prompt for 1 second. The optional argument SECONDS overrides the number of seconds." (let ((message-log-max nil)) - (message "%s%s%s" - (isearch-message-prefix nil isearch-nonincremental) - isearch-message - (apply #'propertize (format " [%s]" string) - isearch-message-properties))) - (sit-for (or seconds 1))) + (important-message + (or seconds 1) nil "%s%s%s" + (isearch-message-prefix nil isearch-nonincremental) + isearch-message + (apply #'propertize (format " [%s]" string) + isearch-message-properties)))) (isearch-define-mode-toggle lax-whitespace " " nil "In ordinary search, toggles the value of the variable @@ -2777,8 +2777,7 @@ isearch-yank-until-char (search-forward (char-to-string char) nil nil arg) (forward-char -1)) (search-failed - (message "`%c' not found" char) - (sit-for 2))) + (important-message 2 nil "`%c' not found" char))) (point))))) (defun isearch-yank-line (&optional arg) diff --git a/lisp/proced.el b/lisp/proced.el index 3435f1ab8cd..9365df95b71 100644 --- a/lisp/proced.el +++ b/lisp/proced.el @@ -2131,8 +2131,7 @@ proced-send-signal ;; the command can be used more flexibly in noninteractive ways, too. (unless (get 'proced-send-signal 'proced-outdated) (put 'proced-send-signal 'proced-outdated t) - (message "Outdated usage of `proced-send-signal'") - (sit-for 2)) + (important-message 2 nil "Outdated usage of `proced-send-signal'")) (setq process-alist (proced-marked-processes)) (unless signal (let ((pnum (if (= 1 (length process-alist)) diff --git a/lisp/simple.el b/lisp/simple.el index 692c0dacefc..ece98ec109d 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -4794,6 +4794,14 @@ max-mini-window-lines ((integerp max-mini-window-height) max-mini-window-height) (t 1))) +(defun important-message (seconds nodisp format-string &rest args) + "Display an important message in the echo area. +Make sure that message stays displayed for the specified number of SECONDS. +The arguments SECONDS and NODISP are the same as in `sit-for'. +The arguments FORMAT-STRING and ARGS are the same as in `message'." + (apply #'message format-string args) + (sit-for seconds nodisp)) + (defun display-message-or-buffer (message &optional buffer-name action frame) "Display MESSAGE in the echo area if possible, otherwise in a pop-up buffer. MESSAGE may be either a string or a buffer. @@ -9772,10 +9780,11 @@ set-variable (t "globally")))) (val (progn (when obsolete - (message (concat "`%S' is obsolete; " - (if (symbolp obsolete) "use `%S' instead" "%s")) - var obsolete) - (sit-for 3)) + (important-message + 3 nil + (concat "`%S' is obsolete; " + (if (symbolp obsolete) "use `%S' instead" "%s")) + var obsolete)) (if prop ;; Use VAR's `variable-interactive' property ;; as an interactive spec for prompting. diff --git a/lisp/subr.el b/lisp/subr.el index df28989b399..d77d3ab25fe 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -3404,8 +3404,8 @@ read-passwd (setq success first)) (and (arrayp first) (clear-string first)) (and (arrayp second) (clear-string second)) - (message "Password not repeated accurately; please start over") - (sit-for 1)))) + (important-message + 1 nil "Password not repeated accurately; please start over")))) success) (let (minibuf) (minibuffer-with-setup-hook @@ -3469,8 +3469,7 @@ read-number ((stringp str) (read str)))) (error nil))) (unless (numberp n) - (message "Please enter a number.") - (sit-for 1) + (important-message 1 nil "Please enter a number.") t))) n)) diff --git a/lisp/tooltip.el b/lisp/tooltip.el index 4537fdf8087..d03073ec4c2 100644 --- a/lisp/tooltip.el +++ b/lisp/tooltip.el @@ -275,8 +275,7 @@ tooltip-show tooltip-x-offset tooltip-y-offset)) (error - (message "Error while displaying tooltip: %s" error) - (sit-for 1) + (important-message 1 nil "Error while displaying tooltip: %s" error) (message "%s" text))))) (declare-function x-hide-tip "xfns.c" ()) diff --git a/lisp/userlock.el b/lisp/userlock.el index db94bb214e6..72d5595770b 100644 --- a/lisp/userlock.el +++ b/lisp/userlock.el @@ -83,9 +83,10 @@ ask-user-about-lock (cond ((null answer) (beep) ;; FIXME: Why do we use "?" here and "C-h" below? - (message (substitute-command-keys - "Please type \\`q', \\`s', or \\`p'; or \\`?' for help")) - (sit-for 3)) + (important-message + 3 nil + (substitute-command-keys + "Please type \\`q', \\`s', or \\`p'; or \\`?' for help"))) ((eq (cdr answer) 'help) (ask-user-about-lock-help) (setq answer nil)) diff --git a/lisp/view.el b/lisp/view.el index 2ac7479739f..6f6bcfce2c3 100644 --- a/lisp/view.el +++ b/lisp/view.el @@ -900,9 +900,10 @@ view-search (overlay-put view-overlay 'face view-highlight-face) (beginning-of-line) (view-recenter)) - (message "Can't find occurrence %d of %s%s" - times (if no "no " "") regexp) - (sit-for 4)))) + (important-message + 4 nil + "Can't find occurrence %d of %s%s" + times (if no "no " "") regexp)))) ;; This is the dumb approach, looking at each line. The original ;; version of this function looked like it might have been trying to diff --git a/lisp/cedet/semantic/bovine/c.el b/lisp/cedet/semantic/bovine/c.el index cf5ce1761a8..960c39feaf3 100644 --- a/lisp/cedet/semantic/bovine/c.el +++ b/lisp/cedet/semantic/bovine/c.el @@ -916,8 +916,7 @@ semantic-c-parse-lexical-token (format "There was an error initializing %s in buffer \"%s\". Debug your hooks? " mode (buffer-name))) (semantic-c-debug-mode-init mode) - (message "Macro parsing state may be broken...") - (sit-for 1)))) + (important-message 1 nil "Macro parsing state may be broken...")))) ) ; save match data ;; Hack in mode-local diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el index 82c6c03a592..5871ae16b04 100644 --- a/lisp/emacs-lisp/checkdoc.el +++ b/lisp/emacs-lisp/checkdoc.el @@ -694,20 +694,17 @@ checkdoc-interactive-loop 'automatic-then-never))) (if (not fixed) (progn - (message "A Fix was not available.") - (sit-for 2)) + (important-message 2 nil "A Fix was not available.")) (setq err-list (cdr err-list)))) (beginning-of-defun) (let ((ne (funcall findfunc nil))) (if ne (setq err-list (cons ne err-list)) (cond ((not err-list) - (message "No More Stylistic Errors.") - (sit-for 2)) + (important-message 2 nil "No More Stylistic Errors.")) (t - (message - "No Additional style errors. Continuing...") - (sit-for 2)))))) + (important-message 2 nil + "No Additional style errors. Continuing...")))))) ;; Move to the next error (if available) ((memq c '(?n ?\s)) (let ((ne (funcall findfunc nil))) @@ -716,9 +713,8 @@ checkdoc-interactive-loop (setq returnme err-list err-list nil) (if (not err-list) - (message "No More Stylistic Errors.") - (message "No Additional style errors. Continuing...")) - (sit-for 2)) + (important-message 2 nil "No More Stylistic Errors.") + (important-message 2 nil "No Additional style errors. Continuing..."))) (setq err-list (cons ne err-list))))) ;; Go backwards in the list of errors ((memq c '(?p ?\C-?)) @@ -727,8 +723,7 @@ checkdoc-interactive-loop (setq err-list (cdr err-list)) (goto-char (cdr (car err-list))) (beginning-of-defun)) - (message "No Previous Errors.") - (sit-for 2))) + (important-message 2 nil "No Previous Errors."))) ;; Edit the buffer recursively. ((eq c ?e) (checkdoc-recursive-edit @@ -741,8 +736,7 @@ checkdoc-interactive-loop (if showstatus (setq returnme err-list err-list nil) - (message "No More Stylistic Errors.") - (sit-for 2)) + (important-message 2 nil "No More Stylistic Errors.")) (setq err-list (cons ne err-list))))) ;; Quit checkdoc ((eq c ?q) diff --git a/lisp/emacs-lisp/helper.el b/lisp/emacs-lisp/helper.el index 0446109f5ac..a4c1415e694 100644 --- a/lisp/emacs-lisp/helper.el +++ b/lisp/emacs-lisp/helper.el @@ -87,9 +87,9 @@ Helper-help-scroller (defun Helper-help-options () "Describe help options." (interactive) - (message (substitute-command-keys - "\\`c' (key briefly), \\`m' (mode), \\`k' (key), \\`b' (bindings)")) - (sit-for 4)) + (important-message + 4 nil (substitute-command-keys + "\\`c' (key briefly), \\`m' (mode), \\`k' (key), \\`b' (bindings)"))) (defun Helper-describe-key-briefly (key) "Briefly describe binding of KEY." diff --git a/lisp/emacs-lisp/map-ynp.el b/lisp/emacs-lisp/map-ynp.el index b603f2e6d0b..a26764b6e50 100644 --- a/lisp/emacs-lisp/map-ynp.el +++ b/lisp/emacs-lisp/map-ynp.el @@ -250,10 +250,10 @@ map-y-or-n-p (funcall try-again)) (t ;; Random char. - (message "Type %s for help." - (key-description (vector help-char))) (beep) - (sit-for 1) + (important-message + 1 nil "Type %s for help." + (key-description (vector help-char))) (funcall try-again)))) (prompt (funcall actor elt) @@ -372,8 +372,7 @@ read-answer (interactive) (delete-minibuffer-contents) (beep) - (message message) - (sit-for 2))) + (important-message 2 nil message))) map) read-answer-map--memoize)))) answer) @@ -415,8 +414,7 @@ read-answer answers-with-help ",\n") ".\n"))) (beep) - (message message) - (sit-for 2))) + (important-message 2 nil message))) answer)) ;;; map-ynp.el ends here diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 51c81b9d2f6..3afa33c3068 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -3254,13 +3254,13 @@ compilation-find-file (origname name)) (cond ((not (file-exists-p name)) - (message "Cannot find file `%s'" name) - (ding) (sit-for 2)) + (ding) + (important-message 2 nil "Cannot find file `%s'" name)) ((and (file-directory-p name) (not (file-exists-p (setq name (compilation--expand-fn name filename))))) - (message "No `%s' in directory %s" filename origname) - (ding) (sit-for 2)) + (ding) + (important-message 2 nil "No `%s' in directory %s" filename origname)) (t (setq buffer (find-file-noselect name)))))))) ;; Make intangible overlays tangible. diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el index 17af1f1d926..7c6aee1cbeb 100644 --- a/lisp/textmodes/ispell.el +++ b/lisp/textmodes/ispell.el @@ -2375,9 +2375,9 @@ ispell-command-loop ;; This may have alignment errors if current line is edited (if (marker-position ispell-recursive-edit-marker) (progn - (message "Only one recursive edit session supported") (beep) - (sit-for 2)) + (important-message + 2 nil "Only one recursive edit session supported")) (set-marker ispell-recursive-edit-marker start) ;;(set-marker ispell-region-end reg-end) (and ispell-highlight-p ; unhighlight @@ -2768,8 +2768,7 @@ ispell-parse-output (substring output 2)) ; return root word ((equal 0 (string-match "[\ra-zA-Z]" output)) (ding) ; error message from ispell! - (message "Ispell error: %s" output) - (sit-for 5) + (important-message 5 nil "Ispell error: %s" output) nil) (t ; need to process &, ?, and #'s (let ((type (aref output 0)) ; &, ?, or # @@ -3335,9 +3334,8 @@ ispell-tex-arg-end (while (looking-at "[ \t\n]*\\[") (forward-sexp)) (forward-sexp (or arg 1))) (error - (message "Error skipping s-expressions at point %d." (point)) (beep) - (sit-for 2)))) + (important-message 2 nil "Error skipping s-expressions at point %d." (point))))) (defun ispell-ignore-fcc (start end) @@ -3413,10 +3411,10 @@ ispell-skip-region (setq alist (cdr alist)))))) (if (and (= start (point)) (null null-skip)) (progn - (message "Matching region end for `%s' point %d not found" - key (point)) (beep) - (sit-for 2))))) + (important-message + 2 nil "Matching region end for `%s' point %d not found" + key (point)))))) (defun ispell-get-line (start end in-comment) @@ -4168,8 +4166,7 @@ ispell-buffer-local-parsing (ispell-send-string "-\n~nroff\n")) ((string-search "~" string) ; Set extended character mode. (ispell-send-string (concat string "\n"))) - (t (message "Invalid Ispell Parsing argument!") - (sit-for 2)))))))) + (t (important-message 2 nil "Invalid Ispell Parsing argument!")))))))) ;; Can kill the current ispell process diff --git a/lisp/vc/ediff-diff.el b/lisp/vc/ediff-diff.el index 83bd7cde12f..381d24f1c77 100644 --- a/lisp/vc/ediff-diff.el +++ b/lisp/vc/ediff-diff.el @@ -222,15 +222,15 @@ ediff-make-diff2-buffer (let ((file1-size (ediff-file-size file1)) (file2-size (ediff-file-size file2))) (cond ((not (numberp file1-size)) - (message "Can't find file: %s" - (ediff-abbreviate-file-name file1)) - (sit-for 2) + (important-message + 2 nil "Can't find file: %s" + (ediff-abbreviate-file-name file1)) ;; 1 is an error exit code 1) ((not (numberp file2-size)) - (message "Can't find file: %s" - (ediff-abbreviate-file-name file2)) - (sit-for 2) + (important-message + 2 nil "Can't find file: %s" + (ediff-abbreviate-file-name file2)) ;; 1 is an error exit code 1) (t ;; this erases the diff buffer automatically diff --git a/lisp/vc/ediff-ptch.el b/lisp/vc/ediff-ptch.el index f8d4c1c1c4b..431f6becc10 100644 --- a/lisp/vc/ediff-ptch.el +++ b/lisp/vc/ediff-ptch.el @@ -364,8 +364,7 @@ ediff-fixup-patch-map (setq directory nil) (setq directory t) (beep) - (message "%s is a directory" user-file) - (sit-for 2))) + (important-message 2 nil "%s is a directory" user-file))) (setcar (ediff-get-session-objA session-info) (cons user-file user-file)))) (setcar proposed-file-names @@ -478,8 +477,7 @@ ediff-fixup-patch-map (if (not (file-directory-p target)) (setq directory nil) (beep) - (message "%s is a directory" target) - (sit-for 2))) + (important-message 2 nil "%s is a directory" target))) (setcar session-file-object target)))))) ediff-patch-map) )) diff --git a/lisp/vc/ediff-util.el b/lisp/vc/ediff-util.el index 597d8a5e643..425b1c60e5a 100644 --- a/lisp/vc/ediff-util.el +++ b/lisp/vc/ediff-util.el @@ -1047,9 +1047,9 @@ ediff-toggle-read-only (t (setq toggle-ro-cmd 'read-only-mode) (beep 1) (beep 1) - (message - "Boy, this is risky! Don't modify this file...") - (sit-for 3)))) ; let the user see the warning + (important-message + 3 nil ; let the user see the warning + "Boy, this is risky! Don't modify this file...")))) (if (and toggle-ro-cmd (string-match "read-only-mode" (symbol-name toggle-ro-cmd))) (save-excursion @@ -2001,11 +2001,12 @@ ediff-copy-diff (setq messg (ediff-save-diff-region n to-buf-type reg-to-delete)))) - (error (message "ediff-copy-diff: %s %s" - (car conds) - (mapconcat #'prin1-to-string (cdr conds) " ")) - (beep 1) - (sit-for 2) ; let the user see the error msg + (error (beep 1) + (important-message + 2 nil ; let the user see the error msg + "ediff-copy-diff: %s %s" + (car conds) + (mapconcat #'prin1-to-string (cdr conds) " ")) (setq saved-p nil) ))) ) @@ -2692,9 +2693,8 @@ ediff-write-merge-buffer-and-maybe-kill (save-buffer)) (if show-file (progn - (message "Merge buffer saved in: %s" file) (set-buffer-modified-p nil) - (sit-for 3))) + (important-message 3 nil "Merge buffer saved in: %s" file))) (if (and (not save-and-continue) (y-or-n-p "Merge buffer saved. Now kill the buffer? ")) @@ -3231,8 +3231,9 @@ ediff-save-buffer (ediff-get-buffer (ediff-char-to-buftype last-command-event))) ((eq last-command-event ?d) - (message "Saving diff output ...") - (sit-for 1) ; let the user see the message + (important-message + 1 nil ; let the user see the message + "Saving diff output ...") (cond ((and arg (ediff-buffer-live-p ediff-diff-buffer)) ediff-diff-buffer) ((ediff-buffer-live-p ediff-custom-diff-buffer) @@ -3442,10 +3443,10 @@ ediff-inferior-compare-regions nil) ((equal answer "")) (t (beep 1) - (message + (important-message + 2 nil "Valid values are %s" (mapconcat #'char-to-string possibilities " or ")) - (sit-for 2) t)) (let ((cursor-in-echo-area t)) (message "Enter the 1st buffer you want to compare (%s): " @@ -3461,10 +3462,10 @@ ediff-inferior-compare-regions nil) ((equal answer "")) (t (beep 1) - (message + (important-message + 2 nil "Valid values are %s" (mapconcat #'char-to-string possibilities " or ")) - (sit-for 2) t)) (let ((cursor-in-echo-area t)) (message "Enter the 2nd buffer you want to compare (%s): " --=-=-=-- From unknown Fri Jun 20 07:27:51 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 15 Feb 2024 12:24:16 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator