bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67393: 29.1; Slow to open file if autosave exists


From: Eli Zaretskii
Subject: bug#67393: 29.1; Slow to open file if autosave exists
Date: Mon, 25 Dec 2023 18:58:32 +0200

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]