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: Sun, 24 Dec 2023 22:19:20 +0200

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





reply via email to

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