unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: materus213@gmail.com, 67393@debbugs.gnu.org,
	stefankangas@gmail.com, juri@linkov.net
Subject: bug#67393: 29.1; Slow to open file if autosave exists
Date: Mon, 25 Dec 2023 18:58:32 +0200	[thread overview]
Message-ID: <83jzp29q2v.fsf@gnu.org> (raw)
In-Reply-To: <87zfxymdk6.fsf@localhost> (message from Ihor Radchenko on Mon, 25 Dec 2023 16:50:33 +0000)

> From: Ihor Radchenko <yantar92@posteo.net>
> 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 <eliz@gnu.org> 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: <filename> 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?





  reply	other threads:[~2023-12-25 16:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-23  0:28 bug#67393: 29.1; Slow to open file if autosave exists materus213
2023-11-23  6:51 ` Eli Zaretskii
2023-12-22 14:56   ` Stefan Kangas
2023-12-23 14:34     ` Ihor Radchenko
2023-12-23 17:23       ` Juri Linkov
2023-12-23 18:05         ` Ihor Radchenko
2023-12-24 17:34           ` Juri Linkov
2023-12-24 18:39             ` Eli Zaretskii
2023-12-24 19:03               ` Ihor Radchenko
2023-12-24 19:28                 ` Eli Zaretskii
2023-12-24 19:49                   ` Ihor Radchenko
2023-12-24 20:19                     ` Eli Zaretskii
2023-12-25 16:50                       ` Ihor Radchenko
2023-12-25 16:58                         ` Eli Zaretskii [this message]
2023-12-25 17:18                           ` Ihor Radchenko
2023-12-25 17:34                             ` Eli Zaretskii
2023-12-25 18:40                               ` Ihor Radchenko
2023-12-25 19:08                                 ` Eli Zaretskii
2023-12-25 20:17                                   ` Ihor Radchenko
2023-12-27 12:34                                     ` Eli Zaretskii
2023-12-28 13:59                                       ` Ihor Radchenko
2023-12-27 17:20               ` Juri Linkov
2023-12-27 17:33                 ` Eli Zaretskii
2023-12-28  7:57                   ` Juri Linkov
2024-01-16 16:36                     ` Juri Linkov
2024-01-16 17:10                       ` Eli Zaretskii
2024-01-16 17:43                         ` Juri Linkov
2024-01-16 18:51                           ` Eli Zaretskii
2024-01-17 16:48                             ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83jzp29q2v.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=67393@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=materus213@gmail.com \
    --cc=stefankangas@gmail.com \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).