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

[Juri Linkov <juri@linkov.net>]

>> >> +** 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.