GNU bug report logs - #40774
Error messages shouldn't be hidden when the user is idle

Previous Next

Full log

Message #112 received at 40774 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 40774 <at> debbugs.gnu.org, larsi <at> gnus.org, ndame <at> protonmail.com
Subject: Re: bug#40774: Error messages shouldn't be hidden when the user is
 idle
Date: Sun, 12 Dec 2021 21:49:26 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org,  40774 <at> debbugs.gnu.org,  ndame <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.