From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#67393: 29.1; Slow to open file if autosave exists Date: Mon, 25 Dec 2023 18:58:32 +0200 Message-ID: <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1929"; mail-complaints-to="usenet@ciao.gmane.io" Cc: materus213@gmail.com, 67393@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 25 17:59:14 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rHoIM-0000HK-Kl for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 Dec 2023 17:59:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHoI5-0004Ig-If; Mon, 25 Dec 2023 11:58:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHoI4-0004IR-7N for bug-gnu-emacs@gnu.org; Mon, 25 Dec 2023 11:58:56 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rHoI3-00045U-Vn for bug-gnu-emacs@gnu.org; Mon, 25 Dec 2023 11:58:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rHoIA-00051P-JL for bug-gnu-emacs@gnu.org; Mon, 25 Dec 2023 11:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Dec 2023 16:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67393 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 67393-submit@debbugs.gnu.org id=B67393.170352353119284 (code B ref 67393); Mon, 25 Dec 2023 16:59:02 +0000 Original-Received: (at 67393) by debbugs.gnu.org; 25 Dec 2023 16:58:51 +0000 Original-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 Original-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 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 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==; In-Reply-To: <87zfxymdk6.fsf@localhost> (message from Ihor Radchenko on Mon, 25 Dec 2023 16:50:33 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:276875 Archived-At: > 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?