bug#40774: Error messages shouldn't be hidden when the user is idle

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

If a message is printed in the echo area then it can be hidden in two
ways: either the user uses some command and the echo area is cleared
automatically or an other message comes which replaces the previous
one.

I use several timers which perform recurring or background tasks,
e.g. fetching things from the network. When there is an error in such
a timer then often I only know about it by noticing that the task does
not produce the usual results, e.g. fails to update something, because
other progress messages hide the printed errors.

A better way can be if error messages can't be hidden if the user is
idle. When I'm using emacs then I usually notice the error, but if I'm
in an other app and the error occurs in the meantime then often it's
hidden by a progress message by the time I switch back to emacs.

So when the user is not idle then things should work as today. But if
the user is idle (e.g. uses an other app or is away from the computer)
then error messages should not be hidden by other messages, rather
they should all be shown in a multiline echo area, so when the user
gets back to emacs he can see all the errors which happened while he
was away.

[-- Attachment #2: Type: text/html, Size: 1479 bytes --]

bug#40774: Error messages shouldn't be hidden when the user is idle

[Drew Adams]

> If a message is printed in the echo area then it can be hidden in two ways: either the user uses some command and the echo area is cleared automatically or an other message comes which replaces the previous one.

> I use several timers which perform recurring or background tasks, e.g. fetching things from the network. When there is an error in such a timer then often I only know about it by noticing that the task does not produce the usual results, e.g. fails to update something, because other progress messages hide the printed errors.

> A better way can be if error messages can't be hidden if the user is idle. When I'm using emacs then I usually notice the error, but if I'm in an other app and the error occurs in the meantime then often it's hidden by a progress message by the time I switch back to emacs.

> So when the user is not idle then things should work as today. But if the user is idle (e.g. uses an other app or is away from the computer) then error messages should not be hidden by other messages, rather they should all be shown in a multiline echo area, so when the user gets back to emacs he can see all the errors which happened while he was away.

My suggestion would instead be this:

As an _option_ (i.e. one can easily turn it off), have buffer `*Messages*' be displayed on an idle timer.

You can do this yourself, now, BTW.  But it might be good for Emacs to offer this out of the box.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>
> My suggestion would instead be this:
>
> As an option (i.e. one can easily turn it off), have buffer `Messages' be displayed on an idle timer.

This is not the same, because if there are progress messages too then errors
can be drowned in the noise, the user may not notice the error, and the user
usually doesn't care about progress message history.

It's much better if emacs collects the errors while the user is away and shows
them when the user is back, because if the computer can collect these then it
should do it instead of the user.

And when the user is back and sees the errors then he knows about them right
away without having to parse the Messages buffer visually.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Drew Adams]

> > My suggestion would instead be this: As an option,
> > have buffer `Messages' be displayed on an idle timer.
> 
> This is not the same, because if there are progress messages too then errors can be drowned in the noise, the user may not notice the error, and the user usually doesn't care about progress message history.
> 
> It's much better if emacs collects the errors while the user is away and shows
> them when the user is back, because if the computer can collect these then it should do it instead of the user.
> 
> And when the user is back and sees the errors then he knows about them right away without having to parse the Messages buffer visually.

The same trivial messages that pollute *Messages* would pollute your multi-line echo area.

Showing *Messages* has the same effect of showing your multi-line echo area, no? Except that it's not transient.

Emacs "collects the errors while the user is away, and shows them when the user is back" is exactly what *Messages* does.

Even now, even without popping up Messages automatically after some idle period, you can just click `mouse-1' in the echo area to pop it up.  Or use `C-h e' to do the same thing.

(See also: https://stackoverflow.com/q/4682033/729907.)
___

BTW, I wonder if buffer *Messages* shouldn't have a menu-bar menu, with a few items that do things like filter temporarily in various ways, change `message-log-max', etc.  Some things a user might want to do with the buffer content aren't necessarily obvious.

IOW, *Messages* could probably be made more directly useful than it is now.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>
> The same trivial messages that polluteMessages would pollute your multi-line echo area.
>

No, because the echo are in the idle case would show only the actual error messages,
not the trivial progress messages.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 16:21:38 +0000
> From: ndame via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> If a message is printed in the echo area then it can be hidden in two
> ways: either the user uses some command and the echo area is cleared
> automatically or an other message comes which replaces the previous
> one.
> 
> I use several timers which perform recurring or background tasks,
> e.g. fetching things from the network. When there is an error in such
> a timer then often I only know about it by noticing that the task does
> not produce the usual results, e.g. fails to update something, because
> other progress messages hide the printed errors.

That's why we have the *Messages* buffer, where all the messages are
logged, even those that aren't shown in the echo area.  A simple
solution to your use case is to have the *Messages* buffer shown in a
window at all times.

> So when the user is not idle then things should work as today. But if
> the user is idle (e.g. uses an other app or is away from the computer)
> then error messages should not be hidden by other messages, rather
> they should all be shown in a multiline echo area, so when the user
> gets back to emacs he can see all the errors which happened while he
> was away.

How do you define "user is idle"?  is that only keyboard input, or
does that include other kinds of input as well?  On a modern graphical
system, it isn't trivial to decide whether the user is idle, because
there are input events that come from the system, not just from the
user making keyboard or mouse gestures.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>
> That's why we have theMessages buffer, where all the messages are
> logged, even those that aren't shown in the echo area. A simple
> solution to your use case is to have the Messages buffer shown in a
> window at all times.

I don't have screen real estate to constantly show the Messages buffer
and it still has the problem that other messages drown the error
messages.

But I can solve this problem for myself if needed. I only submitted
the idea here, because I felt it could be useful for others too.

>
> How do you define "user is idle"?

The same definition what run-with-idle-timer uses is suitable.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 17:38:47 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org>
> 
> > How do you define "user is idle"?
> 
> The same definition what run-with-idle-timer uses is suitable.

Are you sure?  That defines when _Emacs_ is idle, which is not the
same thing.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Wednesday, April 22, 2020 8:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> >
> > > How do you define "user is idle"?
> >
> > The same definition what run-with-idle-timer uses is suitable.
>
> Are you sure? That defines when Emacs is idle, which is not the
> same thing.

Yes, I meant "user is idle" from Emacs' point of view. I should have
been more precise. I wrote: "the user is idle (e.g. uses an other app
or is away from the computer)".

So this feature comes into play when the user is idle in Emacs,
e.g. uses an other app, so doesn't look at the Emacs window
and can miss error messages.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 18:21:48 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org>
> 
> > > The same definition what run-with-idle-timer uses is suitable.
> >
> > Are you sure? That defines when Emacs is idle, which is not the
> > same thing.
> 
> Yes, I meant "user is idle" from Emacs' point of view. I should have
> been more precise. I wrote: "the user is idle (e.g. uses an other app
> or is away from the computer)".
> 
> So this feature comes into play when the user is idle in Emacs,
> e.g. uses an other app, so doesn't look at the Emacs window
> and can miss error messages.

What if the user is looking at another application, and Emacs runs a
prolonged operation of sorts, for example, indexing some large
directory?

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>
> What if the user is looking at another application, and Emacs runs a
> prolonged operation of sorts, for example, indexing some large
> directory?

I don't get what you're getting at.

If the prolonged operation does not stop with an error then nothing
happens. If the operation stops with an error then the error
will be in the echo  area when the user switches back to emacs.

This feature only comes into play if a message is printed to the
echo area, the message is an error message (sent by error, signal, etc.)
and the user is idle in emacs. Then the error (or errors) is stored,
so if some other progress message arrives when the user is idle then
it does not hide the error, it stays in the echo area.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 18:43:48 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org>
> 
> >
> > What if the user is looking at another application, and Emacs runs a
> > prolonged operation of sorts, for example, indexing some large
> > directory?
> 
> I don't get what you're getting at.

You want the Emacs behavior to change depending on whether "the user
is idle" or not, right?  If the practical implementation of that will
be "when Emacs is idle", you might not have the behavior you wanted,
because Emacs might _not_ be idle when the user is.

I hope this clarifies the point I was trying to make.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>
> You want the Emacs behavior to change depending on whether "the user
> is idle" or not, right? If the practical implementation of that will
> be "when Emacs is idle", you might not have the behavior you wanted,
> because Emacs might not be idle when the user is.

If Emacs prints a message then the message function can check if the
user is idle using the same condition what run-with-idle-timer
uses and if so then it can handle displaying the message in different way.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 18:53:01 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org>
> 
> > You want the Emacs behavior to change depending on whether "the user
> > is idle" or not, right? If the practical implementation of that will
> > be "when Emacs is idle", you might not have the behavior you wanted,
> > because Emacs might not be idle when the user is.
> 
> If Emacs prints a message then the message function can check if the
> user is idle using the same condition what run-with-idle-timer
> uses and if so then it can handle displaying the message in different way.

But that's exactly the problem I see with your proposed strategy:
when Emacs prints a message, it is _never_ idle, by definition.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>
> But that's exactly the problem I see with your proposed strategy:
> when Emacs prints a message, it is never idle, by definition.


But the condition is not "when Emacs is idle", but "when the user
is idle". So Emacs can do some processing, running some timers,
printing messages while the user is idle in Emacs, right?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 19:10:36 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org>
> 
> > But that's exactly the problem I see with your proposed strategy:
> > when Emacs prints a message, it is never idle, by definition.
> 
> But the condition is not "when Emacs is idle", but "when the user
> is idle". So Emacs can do some processing, running some timers,
> printing messages while the user is idle in Emacs, right?

We are going in circles.

You want Emacs behave two different ways when it is about to show a
message, is that right?  So I'm asking how will Emacs determine, at
that point, whether "the user is idle".  The method Emacs uses to
determine when to run the next idle timer will not work, because when
Emacs is about to print a message, that method will return false,
i.e. tell that the user is not idle.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> The method Emacs uses to
> determine when to run the next idle timer will not work, because when
> Emacs is about to print a message, that method will return false,
> i.e. tell that the user is not idle.

OK, I didn't check how idle timers worked I just assumed the same
method can be used.

Then I guess the time of the last command can be used if it's
available. If the user did not invoke any command for a while then
we can assume  he's idle.

And it doesn't really matter if the determination of idleness is not
precise, because it only means that errors occuring during this time
won't be hidden by regular messages, they stay in the echo area.

And anytime the user actually invokes a command the echo area is
cleared as it works currently.

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>  The method Emacs uses to
> determine when to run the next idle timer will not work,

It just occurred to me there is no need for idle check at all.

The echo area is currently automatically cleared when the user
performs a command. Otherwise, a new message can override
the echo area.

Only the latter needs to be changed, so that a new message does
not erase error messages.

So if emacs is left alone then arriving error messages are
accumulated and shown in a multiline echo area. If a new regular
message arrives then it is shown at the bottom of the multiline
echo area with the earlier error messages above.

And when the user comes back and performs a command then
the echo area is cleared as usual.

So the only change needed is that error messages can only be cleared
from the echo area by the user doing some command. Otherwise they
are collected and shown.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

> So the only change needed is that error messages can only be cleared
> from the echo area by the user doing some command. Otherwise they
> are collected and shown.

I see now what you mean.  This can be easily implemented with the
following patch.  So you can set `clear-message-function' to a function
that returns a non-nil, and the echo area won't be cleared.

Such predicate function could contain a complex logic, but for testing
you could use just:

  (setq clear-message-function (lambda () t))


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: clear_message.patch --]
[-- Type: text/x-diff, Size: 848 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index 01f272033e..fb9def57ef 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11825,18 +11825,23 @@ set_message_1 (ptrdiff_t a1, Lisp_Object string)
 void
 clear_message (bool current_p, bool last_displayed_p)
 {
+  Lisp_Object preserve = Qnil;
+
   if (current_p)
     {
-      echo_area_buffer[0] = Qnil;
-      message_cleared_p = true;
-
       if (FUNCTIONP (Vclear_message_function))
         {
           ptrdiff_t count = SPECPDL_INDEX ();
           specbind (Qinhibit_quit, Qt);
-          safe_call (1, Vclear_message_function);
+          preserve = safe_call (1, Vclear_message_function);
           unbind_to (count, Qnil);
         }
+
+      if (NILP (preserve))
+        {
+          echo_area_buffer[0] = Qnil;
+          message_cleared_p = true;
+        }
     }
 
   if (last_displayed_p)

bug#40774: Error messages shouldn't be hidden when the user is idle

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I see now what you mean.  This can be easily implemented with the
> following patch.  So you can set `clear-message-function' to a function
> that returns a non-nil, and the echo area won't be cleared.
>
> Such predicate function could contain a complex logic, but for testing
> you could use just:
>
>   (setq clear-message-function (lambda () t))

[...]

> -          safe_call (1, Vclear_message_function);
> +          preserve = safe_call (1, Vclear_message_function);
>            unbind_to (count, Qnil);
>          }
> +
> +      if (NILP (preserve))
> +        {
> +          echo_area_buffer[0] = Qnil;
> +          message_cleared_p = true;
> +        }

It an interesting idea, but I don't think this would be a
backwards-compatible implementation.  Today, the return value of
clear-message-function isn't used, so we have to assume that users of
that variable returns...  whatever.  Giving it semantics now would lead
to the message area being preserved unexpectedly.

Or not, if somebody has used that function to semi-clear the echo area,
and then return nil?

So this would have to be implemented in a different way, unfortunately,
I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> +      if (NILP (preserve))
>> +        {
>> +          echo_area_buffer[0] = Qnil;
>> +          message_cleared_p = true;
>> +        }
>
> It an interesting idea, but I don't think this would be a
> backwards-compatible implementation.  Today, the return value of
> clear-message-function isn't used, so we have to assume that users of
> that variable returns...  whatever.  Giving it semantics now would lead
> to the message area being preserved unexpectedly.

To be able to use clear-message-function in Emacs 29,
we need to issue a notification in Emacs 28 NEWS:

diff --git a/etc/NEWS b/etc/NEWS
index 8e38c3690c..69d00a8bf1 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3327,6 +3327,10 @@ This new 'etc-authors-mode' provides font-locking for displaying the
 \f
 * Incompatible Lisp Changes in Emacs 28.1
 
+---
+** The return value of 'clear-message-function' will change in later releases.
+When it will return a non-nil, the echo area won't be cleared.
+
 +++
 ** Emacs now prints a backtrace when signaling an error in batch mode.
 This makes debugging Emacs Lisp scripts run in batch mode easier.  To
-- 

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 40774@debbugs.gnu.org,  eliz@gnu.org,  ndame@protonmail.com
> Date: Sun, 05 Dec 2021 20:54:20 +0200
> 
> To be able to use clear-message-function in Emacs 29,
> we need to issue a notification in Emacs 28 NEWS:
> 
> diff --git a/etc/NEWS b/etc/NEWS
> index 8e38c3690c..69d00a8bf1 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -3327,6 +3327,10 @@ This new 'etc-authors-mode' provides font-locking for displaying the
>  \f
>  * Incompatible Lisp Changes in Emacs 28.1
>  
> +---
> +** The return value of 'clear-message-function' will change in later releases.
> +When it will return a non-nil, the echo area won't be cleared.
> +

We never did anything like that before, AFAIR.  Why is this needed,
and how is this change different from any other change in behavior?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> +** The return value of 'clear-message-function' will change in later releases.
> +When it will return a non-nil, the echo area won't be cleared.

I think I opined that we probably shouldn't introduce any semantics for
these functions here, because it might break people's code in subtle
ways.

So if we want this, we should probably introduce a new facility of some
kind (and perhaps obsolete the old one), to have an orderly transition.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> +** The return value of 'clear-message-function' will change in later releases.
>> +When it will return a non-nil, the echo area won't be cleared.
>
> I think I opined that we probably shouldn't introduce any semantics for
> these functions here, because it might break people's code in subtle
> ways.
>
> So if we want this, we should probably introduce a new facility of some
> kind (and perhaps obsolete the old one), to have an orderly transition.

Maybe, add a new function 'clear-message-function-2',
then in the next release delete 'clear-message-function',
and after the next release rename 'clear-message-function-2' to
'clear-message-function'.  Sorry, couldn't resist, this is not serious 🤭

But really it's not worth the trouble.  I counted 60 incompatible
Lisp changes in Emacs 28.1.  And if we will make this change now,
the authors will have enough time to adapt their code
(though I can't find any use of this new variable anywhere).

bug#40774: Error messages shouldn't be hidden when the user is idle

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Maybe, add a new function 'clear-message-function-2',
> then in the next release delete 'clear-message-function',
> and after the next release rename 'clear-message-function-2' to
> 'clear-message-function'.

Let's call it `new-message-function', and then in the next release,
`new-message-function-final'?  I think that's more up to industry
standard specs.

> But really it's not worth the trouble.  I counted 60 incompatible
> Lisp changes in Emacs 28.1.  And if we will make this change now,
> the authors will have enough time to adapt their code
> (though I can't find any use of this new variable anywhere).

It's true that it's not likely to have been used a lot, so perhaps it's
an acceptable change in semantics.  Perhaps try a search on Github and
see whether anybody's using it there?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> But really it's not worth the trouble.  I counted 60 incompatible
>> Lisp changes in Emacs 28.1.  And if we will make this change now,
>> the authors will have enough time to adapt their code
>> (though I can't find any use of this new variable anywhere).
>
> It's true that it's not likely to have been used a lot, so perhaps it's
> an acceptable change in semantics.  Perhaps try a search on Github and
> see whether anybody's using it there?

I can't find it on Github, and this is understandable - it's a new variable
with quite limited usefulness.  I hoped that even if someone used it,
mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient
as in case of all other incompatible changes.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I can't find it on Github, and this is understandable - it's a new variable
> with quite limited usefulness.  I hoped that even if someone used it,
> mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient
> as in case of all other incompatible changes.

OK; then I'm OK with changing the semantics in Emacs 29 (and noting this
in the NEWS in Emacs 28), but perhaps Eli has an opinion here.  Eli?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 40774@debbugs.gnu.org,  eliz@gnu.org,  ndame@protonmail.com
> Date: Tue, 07 Dec 2021 21:51:14 +0100
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > I can't find it on Github, and this is understandable - it's a new variable
> > with quite limited usefulness.  I hoped that even if someone used it,
> > mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient
> > as in case of all other incompatible changes.
> 
> OK; then I'm OK with changing the semantics in Emacs 29 (and noting this
> in the NEWS in Emacs 28), but perhaps Eli has an opinion here.  Eli?

This is a long discussion, and I chimed in at least twice.  What
exactly is the proposal for which you want my opinion?  Is there some
patch I could study, perhaps?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> > I can't find it on Github, and this is understandable - it's a new variable
>> > with quite limited usefulness.  I hoped that even if someone used it,
>> > mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient
>> > as in case of all other incompatible changes.
>>
>> OK; then I'm OK with changing the semantics in Emacs 29 (and noting this
>> in the NEWS in Emacs 28), but perhaps Eli has an opinion here.  Eli?
>
> This is a long discussion, and I chimed in at least twice.  What
> exactly is the proposal for which you want my opinion?  Is there some
> patch I could study, perhaps?

The updated patch is here:

diff --git a/etc/NEWS b/etc/NEWS
index 55e3216e41..8a92a0dcaa 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -718,6 +718,11 @@ Emacs buffers, like indentation and the like.  The new ert function
 \f
 * Incompatible Lisp Changes in Emacs 29.1
 
+---
+** The return value of 'clear-message-function' is not ignored anymore.
+If the function returns t, then the message is not cleared,
+with the assumption that the function cleared it itself.
+
 ** User option 'mail-source-ignore-errors' is now obsolete.
 The whole mechanism for prompting users to continue in case of
 mail-source errors has been removed, so this option is no longer
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 28bd1df59a..d8db8898f1 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -864,7 +945,11 @@ clear-minibuffer-message
       (setq minibuffer-message-timer nil))
     (when (overlayp minibuffer-message-overlay)
       (delete-overlay minibuffer-message-overlay)
-      (setq minibuffer-message-overlay nil))))
+      (setq minibuffer-message-overlay nil)))
+
+  ;; Return nil telling the caller that the message
+  ;; should be also handled by the caller.
+  nil)
 
 (setq clear-message-function 'clear-minibuffer-message)
 
diff --git a/src/xdisp.c b/src/xdisp.c
index 0ff6286af7..c79168b1be 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12521,18 +12521,23 @@ set_message_1 (void *a1, Lisp_Object string)
 void
 clear_message (bool current_p, bool last_displayed_p)
 {
+  Lisp_Object preserve = Qnil;
+
   if (current_p)
     {
-      echo_area_buffer[0] = Qnil;
-      message_cleared_p = true;
-
       if (FUNCTIONP (Vclear_message_function))
         {
           ptrdiff_t count = SPECPDL_INDEX ();
           specbind (Qinhibit_quit, Qt);
-          safe_call (1, Vclear_message_function);
+          preserve = safe_call (1, Vclear_message_function);
           unbind_to (count, Qnil);
         }
+
+      if (!EQ (preserve, Qt))
+        {
+          echo_area_buffer[0] = Qnil;
+          message_cleared_p = true;
+        }
     }
 
   if (last_displayed_p)
@@ -36232,9 +36237,13 @@ syms_of_xdisp (void)
   DEFVAR_LISP ("clear-message-function", Vclear_message_function,
 	       doc: /* If non-nil, function to clear echo-area messages.
 Usually this function is called when the next input event arrives.
-The function is called without arguments.  It is expected to clear the
-message displayed by its counterpart function specified by
-`set-message-function'.  */);
+It is expected to clear the message displayed by its counterpart
+function specified by `set-message-function'.
+The function is called without arguments.
+If this function returns a non-t value, the message is cleared
+from the echo area as usual.  If this function returns t,
+this means that the message was already handled, and the original
+message text will not be cleared from the echo area.  */);
   Vclear_message_function = Qnil;
 
   DEFVAR_LISP ("redisplay--all-windows-cause", Vredisplay__all_windows_cause,
-- 

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  40774@debbugs.gnu.org,
>   ndame@protonmail.com
> Date: Wed, 08 Dec 2021 21:21:22 +0200
> 
> +** The return value of 'clear-message-function' is not ignored anymore.
> +If the function returns t, then the message is not cleared,
> +with the assumption that the function cleared it itself.

I could perhaps agree to this if the special new behavior was the
result of a very special return value, and only that value.  Having
the new behavior kick in for t is out of the question for the release
branch, as it is highly likely to trip unsuspecting Lisp programs.

Btw, what does the change of the order between the call of
clear-message-function and setting echo_area_buffer[0] to nil mean,
compatibility-wise? won't it also produce different results, even if
the return value is nil?

More generally, I fear that we are trying very hard to tweak a
particular infrastructure for a job for which it was hardly meant.

IOW, shouldn't we provide some completely different optional feature
for this use case?  Like a special buffer that pops up or a special
frame?  Echo-area is not suited for showing large chunks of text, and
my gut feeling is that we will bump into problems on this path.  E.g.,
what happens when there are enough accumulated messages that they can
no longer be shown with the maximum allowed height of the mini-window?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> +** The return value of 'clear-message-function' is not ignored anymore.
>> +If the function returns t, then the message is not cleared,
>> +with the assumption that the function cleared it itself.
>
> I could perhaps agree to this if the special new behavior was the
> result of a very special return value, and only that value.  Having
> the new behavior kick in for t is out of the question for the release
> branch, as it is highly likely to trip unsuspecting Lisp programs.

What a special value would you prefer?  Maybe, a symbol 'no'?

> Btw, what does the change of the order between the call of
> clear-message-function and setting echo_area_buffer[0] to nil mean,
> compatibility-wise? won't it also produce different results, even if
> the return value is nil?

When the return value is nil, it will still clear the echo area.

> More generally, I fear that we are trying very hard to tweak a
> particular infrastructure for a job for which it was hardly meant.

This is the most simple and thus reliable solution.

> IOW, shouldn't we provide some completely different optional feature
> for this use case?  Like a special buffer that pops up or a special
> frame?  Echo-area is not suited for showing large chunks of text, and
> my gut feeling is that we will bump into problems on this path.  E.g.,
> what happens when there are enough accumulated messages that they can
> no longer be shown with the maximum allowed height of the mini-window?

This is exactly what functions bound to clear-message-function intended to do.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  40774@debbugs.gnu.org,  ndame@protonmail.com
> Date: Sun, 12 Dec 2021 21:19:41 +0200
> 
> >> +** The return value of 'clear-message-function' is not ignored anymore.
> >> +If the function returns t, then the message is not cleared,
> >> +with the assumption that the function cleared it itself.
> >
> > I could perhaps agree to this if the special new behavior was the
> > result of a very special return value, and only that value.  Having
> > the new behavior kick in for t is out of the question for the release
> > branch, as it is highly likely to trip unsuspecting Lisp programs.
> 
> What a special value would you prefer?  Maybe, a symbol 'no'?

More like 'no-clear or even 'dont-clear-message, I think.

> > Btw, what does the change of the order between the call of
> > clear-message-function and setting echo_area_buffer[0] to nil mean,
> > compatibility-wise? won't it also produce different results, even if
> > the return value is nil?
> 
> When the return value is nil, it will still clear the echo area.

That wasn't what I asked.  I asked whether the change in the order
could matter.  Specifically, we now set echo_area_buffer[0] to nil
after we run clear-message-function, not before.  Can that affect
some customization of clear-message-function?

> > More generally, I fear that we are trying very hard to tweak a
> > particular infrastructure for a job for which it was hardly meant.
> 
> This is the most simple and thus reliable solution.
> 
> > IOW, shouldn't we provide some completely different optional feature
> > for this use case?  Like a special buffer that pops up or a special
> > frame?  Echo-area is not suited for showing large chunks of text, and
> > my gut feeling is that we will bump into problems on this path.  E.g.,
> > what happens when there are enough accumulated messages that they can
> > no longer be shown with the maximum allowed height of the mini-window?
> 
> This is exactly what functions bound to clear-message-function intended to do.

??? This function is about _clearing_ the echo-area, whereas I was
talking about the _display_ in the echo-area.  I'm saying that I'm not
sure echo-area display is suited for the jobs that this bug wants it
to do.  As an example, I asked what would happen when the echo-area
can no longer be resized to accommodate all the messages that were not
cleared.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> >> +** The return value of 'clear-message-function' is not ignored anymore.
>> >> +If the function returns t, then the message is not cleared,
>> >> +with the assumption that the function cleared it itself.
>> >
>> > I could perhaps agree to this if the special new behavior was the
>> > result of a very special return value, and only that value.  Having
>> > the new behavior kick in for t is out of the question for the release
>> > branch, as it is highly likely to trip unsuspecting Lisp programs.
>>
>> What a special value would you prefer?  Maybe, a symbol 'no'?
>
> More like 'no-clear or even 'dont-clear-message, I think.

I tried to find an existing DEFSYM in syms_of_xdisp,
but it seems there is no suitable symbol, so a new symbol
'dont-clear-message' could be added to syms_of_xdisp.
This is a patch over the previous patch:

diff --git a/src/xdisp.c b/src/xdisp.c
index 9b5b7d49e5..495a84b349 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12533,7 +12533,7 @@ clear_message (bool current_p, bool last_displayed_p)
           unbind_to (count, Qnil);
         }

-      if (!EQ (preserve, Qt))
+      if (!EQ (preserve, Qdont_clear_message))
         {
           echo_area_buffer[0] = Qnil;
           message_cleared_p = true;
@@ -36235,6 +36235,7 @@ syms_of_xdisp (void)
 (which controls how error messages are displayed).  */);
   Vset_message_function = Qnil;

+  DEFSYM (Qdont_clear_message, "dont-clear-message");
   DEFVAR_LISP ("clear-message-function", Vclear_message_function,
 	       doc: /* If non-nil, function to clear echo-area messages.

>> > Btw, what does the change of the order between the call of
>> > clear-message-function and setting echo_area_buffer[0] to nil mean,
>> > compatibility-wise? won't it also produce different results, even if
>> > the return value is nil?
>>
>> When the return value is nil, it will still clear the echo area.
>
> That wasn't what I asked.  I asked whether the change in the order
> could matter.  Specifically, we now set echo_area_buffer[0] to nil
> after we run clear-message-function, not before.  Can that affect
> some customization of clear-message-function?

Actually, it should not affect customizations because such customizations
should not touch the echo-area.  It's the task of clear_message
to handle the echo-area.

>> > More generally, I fear that we are trying very hard to tweak a
>> > particular infrastructure for a job for which it was hardly meant.
>>
>> This is the most simple and thus reliable solution.
>>
>> > IOW, shouldn't we provide some completely different optional feature
>> > for this use case?  Like a special buffer that pops up or a special
>> > frame?  Echo-area is not suited for showing large chunks of text, and
>> > my gut feeling is that we will bump into problems on this path.  E.g.,
>> > what happens when there are enough accumulated messages that they can
>> > no longer be shown with the maximum allowed height of the mini-window?
>>
>> This is exactly what functions bound to clear-message-function intended to do.
>
> ??? This function is about _clearing_ the echo-area, whereas I was
> talking about the _display_ in the echo-area.  I'm saying that I'm not
> sure echo-area display is suited for the jobs that this bug wants it
> to do.  As an example, I asked what would happen when the echo-area
> can no longer be resized to accommodate all the messages that were not
> cleared.

clear-message-function can handle not only echo-area but also e.g.
the minibuffer messages.  In case of the returned value, by using
'dont-clear-message' it can sometimes tell the function clear_message
to not clear the echo-area, so there are no resizing problems.
It doesn't add more lines to the existing echo-area.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  40774@debbugs.gnu.org,  ndame@protonmail.com
> Date: Sun, 12 Dec 2021 22:18:29 +0200
> 
> >> > Btw, what does the change of the order between the call of
> >> > clear-message-function and setting echo_area_buffer[0] to nil mean,
> >> > compatibility-wise? won't it also produce different results, even if
> >> > the return value is nil?
> >>
> >> When the return value is nil, it will still clear the echo area.
> >
> > That wasn't what I asked.  I asked whether the change in the order
> > could matter.  Specifically, we now set echo_area_buffer[0] to nil
> > after we run clear-message-function, not before.  Can that affect
> > some customization of clear-message-function?
> 
> Actually, it should not affect customizations because such customizations
> should not touch the echo-area.  It's the task of clear_message
> to handle the echo-area.

Isn't there some Lisp-visible effect of that, like that the echo-area
will appear empty after the assignment?  If so, then the
clear-message-function was previously running with the echo-area
buffer nil, but now it won't.

> >> > IOW, shouldn't we provide some completely different optional feature
> >> > for this use case?  Like a special buffer that pops up or a special
> >> > frame?  Echo-area is not suited for showing large chunks of text, and
> >> > my gut feeling is that we will bump into problems on this path.  E.g.,
> >> > what happens when there are enough accumulated messages that they can
> >> > no longer be shown with the maximum allowed height of the mini-window?
> >>
> >> This is exactly what functions bound to clear-message-function intended to do.
> >
> > ??? This function is about _clearing_ the echo-area, whereas I was
> > talking about the _display_ in the echo-area.  I'm saying that I'm not
> > sure echo-area display is suited for the jobs that this bug wants it
> > to do.  As an example, I asked what would happen when the echo-area
> > can no longer be resized to accommodate all the messages that were not
> > cleared.
> 
> clear-message-function can handle not only echo-area but also e.g.
> the minibuffer messages.  In case of the returned value, by using
> 'dont-clear-message' it can sometimes tell the function clear_message
> to not clear the echo-area, so there are no resizing problems.
> It doesn't add more lines to the existing echo-area.

I gave an example of how using this for that purpose could be a
problem, and you responded only to that example.  But the problem that
bothers me is much more general, and you are silent about that larger
problem.

I'm asking once again: aren't we trying to use echo-area messages or
minibuffer messages displayed in the mini-window for a job that they
weren't intended to do: showing large amounts of messages at the same
time?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> >> > Btw, what does the change of the order between the call of
>> >> > clear-message-function and setting echo_area_buffer[0] to nil mean,
>> >> > compatibility-wise? won't it also produce different results, even if
>> >> > the return value is nil?
>> >>
>> >> When the return value is nil, it will still clear the echo area.
>> >
>> > That wasn't what I asked.  I asked whether the change in the order
>> > could matter.  Specifically, we now set echo_area_buffer[0] to nil
>> > after we run clear-message-function, not before.  Can that affect
>> > some customization of clear-message-function?
>>
>> Actually, it should not affect customizations because such customizations
>> should not touch the echo-area.  It's the task of clear_message
>> to handle the echo-area.
>
> Isn't there some Lisp-visible effect of that, like that the echo-area
> will appear empty after the assignment?  If so, then the
> clear-message-function was previously running with the echo-area
> buffer nil, but now it won't.

clear-message-function is not intended to do anything with the echo-area.
Its purpose is to notify a subscriber that the message is going to be cleared,
so the subscriber can e.g. clear the message from the minibuffer, etc.
When the subscriber needs to affect the echo-area, it's the purpose
of the proposed return value not to clear the echo-area when the subscriber
asks so via the return value.

>> >> > IOW, shouldn't we provide some completely different optional feature
>> >> > for this use case?  Like a special buffer that pops up or a special
>> >> > frame?  Echo-area is not suited for showing large chunks of text, and
>> >> > my gut feeling is that we will bump into problems on this path.  E.g.,
>> >> > what happens when there are enough accumulated messages that they can
>> >> > no longer be shown with the maximum allowed height of the mini-window?
>> >>
>> >> This is exactly what functions bound to clear-message-function intended to do.
>> >
>> > ??? This function is about _clearing_ the echo-area, whereas I was
>> > talking about the _display_ in the echo-area.  I'm saying that I'm not
>> > sure echo-area display is suited for the jobs that this bug wants it
>> > to do.  As an example, I asked what would happen when the echo-area
>> > can no longer be resized to accommodate all the messages that were not
>> > cleared.
>>
>> clear-message-function can handle not only echo-area but also e.g.
>> the minibuffer messages.  In case of the returned value, by using
>> 'dont-clear-message' it can sometimes tell the function clear_message
>> to not clear the echo-area, so there are no resizing problems.
>> It doesn't add more lines to the existing echo-area.
>
> I gave an example of how using this for that purpose could be a
> problem, and you responded only to that example.  But the problem that
> bothers me is much more general, and you are silent about that larger
> problem.
>
> I'm asking once again: aren't we trying to use echo-area messages or
> minibuffer messages displayed in the mini-window for a job that they
> weren't intended to do: showing large amounts of messages at the same
> time?

Sorry, I still don't understand what do you mean.  What large amounts
of messages?  At what the same time?  This is completely unclear.
Maybe if you give an example, this could help to understand.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  40774@debbugs.gnu.org,  ndame@protonmail.com
> Date: Mon, 13 Dec 2021 20:50:36 +0200
> 
> > Isn't there some Lisp-visible effect of that, like that the echo-area
> > will appear empty after the assignment?  If so, then the
> > clear-message-function was previously running with the echo-area
> > buffer nil, but now it won't.
> 
> clear-message-function is not intended to do anything with the echo-area.
> Its purpose is to notify a subscriber that the message is going to be cleared,
> so the subscriber can e.g. clear the message from the minibuffer, etc.
> When the subscriber needs to affect the echo-area, it's the purpose
> of the proposed return value not to clear the echo-area when the subscriber
> asks so via the return value.

So there will be some effect of this reordering, if some
clear-message-function does something that you say it shouldn't.

> > I gave an example of how using this for that purpose could be a
> > problem, and you responded only to that example.  But the problem that
> > bothers me is much more general, and you are silent about that larger
> > problem.
> >
> > I'm asking once again: aren't we trying to use echo-area messages or
> > minibuffer messages displayed in the mini-window for a job that they
> > weren't intended to do: showing large amounts of messages at the same
> > time?
> 
> Sorry, I still don't understand what do you mean.  What large amounts
> of messages?  At what the same time?  This is completely unclear.
> Maybe if you give an example, this could help to understand.

This whole discussion started from a request to be able to accumulate
messages in the echo-area so that the user who is away could see them
all when he/she comes back from whatever took him/her away.  There
could be quite a lot of messages accumulated during that period, and
the request was to leave them all on display.  For which you proposed
to use clear-message-function in a way that doesn't actually clear
them.

Is the above an accurate description and summary of what is being
proposed here?  If so, is it now clear what kind of job I think
display of echo-area messages was never designed to support?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> > Isn't there some Lisp-visible effect of that, like that the echo-area
>> > will appear empty after the assignment?  If so, then the
>> > clear-message-function was previously running with the echo-area
>> > buffer nil, but now it won't.
>>
>> clear-message-function is not intended to do anything with the echo-area.
>> Its purpose is to notify a subscriber that the message is going to be cleared,
>> so the subscriber can e.g. clear the message from the minibuffer, etc.
>> When the subscriber needs to affect the echo-area, it's the purpose
>> of the proposed return value not to clear the echo-area when the subscriber
>> asks so via the return value.
>
> So there will be some effect of this reordering, if some
> clear-message-function does something that you say it shouldn't.

Of course, when authors decide to shoot themselves in the foot,
we can't prevent this.

>> > I gave an example of how using this for that purpose could be a
>> > problem, and you responded only to that example.  But the problem that
>> > bothers me is much more general, and you are silent about that larger
>> > problem.
>> >
>> > I'm asking once again: aren't we trying to use echo-area messages or
>> > minibuffer messages displayed in the mini-window for a job that they
>> > weren't intended to do: showing large amounts of messages at the same
>> > time?
>>
>> Sorry, I still don't understand what do you mean.  What large amounts
>> of messages?  At what the same time?  This is completely unclear.
>> Maybe if you give an example, this could help to understand.
>
> This whole discussion started from a request to be able to accumulate
> messages in the echo-area so that the user who is away could see them
> all when he/she comes back from whatever took him/her away.  There
> could be quite a lot of messages accumulated during that period, and
> the request was to leave them all on display.  For which you proposed
> to use clear-message-function in a way that doesn't actually clear
> them.
>
> Is the above an accurate description and summary of what is being
> proposed here?  If so, is it now clear what kind of job I think
> display of echo-area messages was never designed to support?

Thanks for explanation, now it's clear where is the misunderstanding.

Actually, the patch for clear-message-function here is unrelated
to the feature that uses set-message-function to accumulate messages
and doesn't use clear-message-function.

The feature here is intended for users who want to always leave
the last displayed message in the echo-area, and never clear it.
It will be possible even to do this conditionally.

For example, when the user wants to leave the message
"Compilation finished" displayed in the echo area even
during navigation in the buffer or when the user types text.
Normally such message will be cleared on any key press,
and thus the user will miss it.  But with such configuration
the user won't miss the message even while using self-inserting
or navigation keys when the message is displayed:

  (setq clear-message-function
        (lambda ()
          (when (string-match-p "^Compilation" (current-message))
            'dont-clear-message)))

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  40774@debbugs.gnu.org,  ndame@protonmail.com
> Date: Tue, 14 Dec 2021 10:35:13 +0200
> 
> > So there will be some effect of this reordering, if some
> > clear-message-function does something that you say it shouldn't.
> 
> Of course, when authors decide to shoot themselves in the foot,
> we can't prevent this.

They might say we shoot them in their foot, by changing the order.

> > This whole discussion started from a request to be able to accumulate
> > messages in the echo-area so that the user who is away could see them
> > all when he/she comes back from whatever took him/her away.  There
> > could be quite a lot of messages accumulated during that period, and
> > the request was to leave them all on display.  For which you proposed
> > to use clear-message-function in a way that doesn't actually clear
> > them.
> >
> > Is the above an accurate description and summary of what is being
> > proposed here?  If so, is it now clear what kind of job I think
> > display of echo-area messages was never designed to support?
> 
> Thanks for explanation, now it's clear where is the misunderstanding.
> 
> Actually, the patch for clear-message-function here is unrelated
> to the feature that uses set-message-function to accumulate messages
> and doesn't use clear-message-function.
> 
> The feature here is intended for users who want to always leave
> the last displayed message in the echo-area, and never clear it.
> It will be possible even to do this conditionally.

But if messages aren't cleared, they will accumulate, and then we get
to the problems I described.  So it is not "unrelated", really.

In any case, if this feature is unrelated, why do you want to have it
on the release branch?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> > This whole discussion started from a request to be able to accumulate
>> > messages in the echo-area so that the user who is away could see them
>> > all when he/she comes back from whatever took him/her away.  There
>> > could be quite a lot of messages accumulated during that period, and
>> > the request was to leave them all on display.  For which you proposed
>> > to use clear-message-function in a way that doesn't actually clear
>> > them.
>> >
>> > Is the above an accurate description and summary of what is being
>> > proposed here?  If so, is it now clear what kind of job I think
>> > display of echo-area messages was never designed to support?
>>
>> Thanks for explanation, now it's clear where is the misunderstanding.
>>
>> Actually, the patch for clear-message-function here is unrelated
>> to the feature that uses set-message-function to accumulate messages
>> and doesn't use clear-message-function.
>>
>> The feature here is intended for users who want to always leave
>> the last displayed message in the echo-area, and never clear it.
>> It will be possible even to do this conditionally.
>
> But if messages aren't cleared, they will accumulate, and then we get
> to the problems I described.  So it is not "unrelated", really.

When the message is not cleared, it will be displayed until another message
will replace it.  This is unrelated to multi-message feature.

> In any case, if this feature is unrelated, why do you want to have it
> on the release branch?

This is another misunderstanding.  I didn't intend to have this
on the release branch.  But since you mentioned it, why not?
Maybe better to apply the patch for clear-message-function
on the release branch?

bug#40774: Error messages shouldn't be hidden when the user is idle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  40774@debbugs.gnu.org,  ndame@protonmail.com
> Date: Tue, 14 Dec 2021 22:54:53 +0200
> 
> >> > This whole discussion started from a request to be able to accumulate
> >> > messages in the echo-area so that the user who is away could see them
> >> > all when he/she comes back from whatever took him/her away.  There
> >> > could be quite a lot of messages accumulated during that period, and
> >> > the request was to leave them all on display.  For which you proposed
> >> > to use clear-message-function in a way that doesn't actually clear
> >> > them.
> >> >
> >> > Is the above an accurate description and summary of what is being
> >> > proposed here?  If so, is it now clear what kind of job I think
> >> > display of echo-area messages was never designed to support?
> >>
> >> Thanks for explanation, now it's clear where is the misunderstanding.
> >>
> >> Actually, the patch for clear-message-function here is unrelated
> >> to the feature that uses set-message-function to accumulate messages
> >> and doesn't use clear-message-function.
> >>
> >> The feature here is intended for users who want to always leave
> >> the last displayed message in the echo-area, and never clear it.
> >> It will be possible even to do this conditionally.
> >
> > But if messages aren't cleared, they will accumulate, and then we get
> > to the problems I described.  So it is not "unrelated", really.
> 
> When the message is not cleared, it will be displayed until another message
> will replace it.  This is unrelated to multi-message feature.

OK, then I guess it was a mistake to discuss this under this
particular bug report.

> > In any case, if this feature is unrelated, why do you want to have it
> > on the release branch?
> 
> This is another misunderstanding.  I didn't intend to have this
> on the release branch.  But since you mentioned it, why not?

Because we are done experimenting on the release branch.  Only
bugfixes should be installed there.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I tried to find an existing DEFSYM in syms_of_xdisp,
> but it seems there is no suitable symbol, so a new symbol
> 'dont-clear-message' could be added to syms_of_xdisp.
> This is a patch over the previous patch:

Makes sense to me, so I've now pushed it (with some changes) to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

>> I can't find it on Github, and this is understandable - it's a new variable
>> with quite limited usefulness.  I hoped that even if someone used it,
>> mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient
>> as in case of all other incompatible changes.
>
> OK; then I'm OK with changing the semantics in Emacs 29 (and noting this
> in the NEWS in Emacs 28), but perhaps Eli has an opinion here.  Eli?

I even further reduced the incompatibilities by using new logic only on
the value 't' returned by the function, instead of any non-nil value.

bug#40774: Error messages shouldn't be hidden when the user is idle

[Juri Linkov]

> So when the user is not idle then things should work as today. But if
> the user is idle (e.g. uses an other app or is away from the computer)
> then error messages should not be hidden by other messages, rather
> they should all be shown in a multiline echo area, so when the user
> gets back to emacs he can see all the errors which happened while he
> was away.

Please try the multiline echo area implemented in
https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00646.html

bug#40774: Error messages shouldn't be hidden when the user is idle

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>
> Please try the multiline echo area implemented in
> https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00646.html

Yes, message stacking is also useful for other reasons. I was the one
who suggested that feature in that thread.

But message stacking clears the stack after a certain timeout which
is different than what I'm suggesting here.

With a timeout error messages could be hidden again by some other
progress message which arrives later.

Keeping error messages while the user is idle means the error
messages stay up indefinitely until the user comes back even if
he comes back, say, an hour later.