GNU bug report logs - #77257
inhibit-message should inhibit echo area clearing too

Previous Next

To reply to this bug, email your comments to 77257 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: bug-gnu-emacs <at> gnu.org
Subject: inhibit-message should inhibit echo area clearing too
Date: Tue, 25 Mar 2025 14:58:35 -0400

(let ((inhibit-message t)) (message "blah")) has the effect of clearing
the echo area.  I'd expect the semantic of inhibit-message to be
preventing all visible side effects of message --- not just some
of them.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Wed, 26 Mar 2025 19:25:06 +0200

> From: Daniel Colascione <dancol <at> dancol.org>
> Date: Tue, 25 Mar 2025 14:58:35 -0400
> 
> 
> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
> the echo area.  I'd expect the semantic of inhibit-message to be
> preventing all visible side effects of message --- not just some
> of them.

If we disable clearing the echo area in that case, should we also
refrain from running echo-area-clear-hook?

Stefan, do you see any potential problems in inhibiting clearing of
the echo area when inhibit-message is bound to a non-nil value?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Daniel Colascione <dancol <at> dancol.org>, 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Wed, 26 Mar 2025 15:21:03 -0400

>> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
>> the echo area.  I'd expect the semantic of inhibit-message to be
>> preventing all visible side effects of message --- not just some
>> of them.
>
> If we disable clearing the echo area in that case, should we also
> refrain from running echo-area-clear-hook?
>
> Stefan, do you see any potential problems in inhibiting clearing of
> the echo area when inhibit-message is bound to a non-nil value?

I'm not sufficiently familiar with the internals of `message` to have
a firm opinion, but it seems to make sense to inhibit *all* the effects.


        Stefan

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

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Daniel Colascione <dancol <at> dancol.org>,
 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Wed, 26 Mar 2025 15:40:02 -0400

[Message part 1 (text/plain, inline)]

On Wed, Mar 26, 2025 at 3:22 PM Stefan Monnier via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:

> >> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
> >> the echo area.  I'd expect the semantic of inhibit-message to be
> >> preventing all visible side effects of message --- not just some
> >> of them.
> >
> > If we disable clearing the echo area in that case, should we also
> > refrain from running echo-area-clear-hook?
> >
> > Stefan, do you see any potential problems in inhibiting clearing of
> > the echo area when inhibit-message is bound to a non-nil value?
>
> I'm not sufficiently familiar with the internals of `message` to have
> a firm opinion, but it seems to make sense to inhibit *all* the effects.
>

I bind (message-log-max nil) when I want message to be super quiet.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: dancol <at> dancol.org, monnier <at> iro.umontreal.ca, 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Thu, 27 Mar 2025 08:12:04 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Wed, 26 Mar 2025 15:40:02 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Daniel Colascione <dancol <at> dancol.org>, 77257 <at> debbugs.gnu.org
> 
> On Wed, Mar 26, 2025 at 3:22 PM Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of
> text editors <bug-gnu-emacs <at> gnu.org> wrote:
> 
>  >> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
>  >> the echo area.  I'd expect the semantic of inhibit-message to be
>  >> preventing all visible side effects of message --- not just some
>  >> of them.
>  >
>  > If we disable clearing the echo area in that case, should we also
>  > refrain from running echo-area-clear-hook?
>  >
>  > Stefan, do you see any potential problems in inhibiting clearing of
>  > the echo area when inhibit-message is bound to a non-nil value?
> 
>  I'm not sufficiently familiar with the internals of `message` to have
>  a firm opinion, but it seems to make sense to inhibit *all* the effects.
> 
> I bind (message-log-max nil) when I want message to be super quiet.

That's unrelated: it controls the logging of messages in the
*Messages* buffer, not their display.  Binding inhibit-message non-nil
doesn't affect the logging in *Messages* in any way, nor should it.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: dick.r.chiang <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 77257 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Thu, 27 Mar 2025 09:09:34 -0400

On March 27, 2025 8:23:40 AM EDT, dick.r.chiang <at> gmail.com wrote:
>I'm afraid the 2022 maintainer's edict takes priority:
>
>"No documentation promised that the previous message will not be
>cleared when inhibit-message is set.  We just avoid displaying new
>messages."
>
>https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58788

Thanks for digging that up. I'd suggest revisiting that resolution. The no-visible-effect behavior is more useful and intuitive than what we have now, and I'm having an hard time seeing how fixing this bug would break anything.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 77257 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Thu, 27 Mar 2025 15:55:41 +0200

> Date: Thu, 27 Mar 2025 09:09:34 -0400
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>, 77257 <at> debbugs.gnu.org
> 
> 
> 
> On March 27, 2025 8:23:40 AM EDT, dick.r.chiang <at> gmail.com wrote:
> >I'm afraid the 2022 maintainer's edict takes priority:
> >
> >"No documentation promised that the previous message will not be
> >cleared when inhibit-message is set.  We just avoid displaying new
> >messages."
> >
> >https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58788
> 
> Thanks for digging that up. I'd suggest revisiting that resolution.

I hope you read everything I wrote in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58788#13, not just the
above small part of it, which was picked selectively to make a point.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: dick.r.chiang <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 77257 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Thu, 27 Mar 2025 10:27:04 -0400

On March 27, 2025 10:09:24 AM EDT, dick.r.chiang <at> gmail.com wrote:
>Your insistence on turning every simple layup into an interminable
>discussion is why the only software management role you're qualified for
>is an unpaid one.


Is this the optimal communication style for getting bugs fixed the way you'd like?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 30 Mar 2025 09:41:18 +0300

> From: Daniel Colascione <dancol <at> dancol.org>
> Date: Tue, 25 Mar 2025 14:58:35 -0400
> 
> 
> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
> the echo area.  I'd expect the semantic of inhibit-message to be
> preventing all visible side effects of message --- not just some
> of them.

We need to preserve the current meaning of t as the value of
inhibit-message, to avoid backward-incompatible changes.  So I added a
third value to mean suppress clearing of the echo-area as well.  Does
the patch below look right?

diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index de06391..6eba3d7 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -405,7 +405,10 @@ Displaying Messages
 @defvar inhibit-message
 When this variable is non-@code{nil}, @code{message} and related functions
 will not display any messages in the Echo Area.  Echo-area messages
-are still logged in the @file{*Messages*} buffer, though.
+are still logged in the @file{*Messages*} buffer, though.  If the value
+is the symbol @code{all}, it also suppresses the clearing of the
+echo-area, such as when @code{message} is called with a @code{nil} or
+empty argument.
 @end defvar
 
 @defmac with-temp-message message &rest body
diff --git a/etc/NEWS b/etc/NEWS
index afa45c5..d3e7903 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -2045,6 +2045,12 @@ This function inserts the special EVENT into the input event queue.
 This event is sent when the device running Emacs enters or leaves the
 sleep state.
 
++++
+** 'inhibit-message' can now inhibit clearing of the echo-area.
+Binding 'inhibit-message' to the special value 'all' will suppress both
+the display of messages and the clearing of the echo-area, such as
+caused by calling 'message' with a nil argument.
+
 ** Function aliases obsolete since Emacs 23.2 have been removed:
 'advertised-undo', 'advertised-widget-backward', and
 'dired-advertised-find-file'.
diff --git a/src/xdisp.c b/src/xdisp.c
index f2b158f..7b894cd 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12386,7 +12386,7 @@ message3 (Lisp_Object m)
       message_dolog (buffer, nbytes, true, multibyte);
       SAFE_FREE ();
     }
-  if (! inhibit_message)
+  if (NILP (Vinhibit_message))
     message3_nolog (m);
 }
 
@@ -13405,7 +13405,7 @@ clear_message (bool current_p, bool last_displayed_p)
 {
   Lisp_Object preserve = Qnil;
 
-  if (current_p)
+  if (current_p && !EQ (Vinhibit_message, Qall))
     {
       if (FUNCTIONP (Vclear_message_function)
           /* FIXME: (bug#63253) Same as for `set-message-function` above.  */
@@ -37582,15 +37582,17 @@ syms_of_xdisp (void)
 settings of `scroll-conservatively'.  */);
   scroll_minibuffer_conservatively = true; /* bug#44070 */
 
-  DEFVAR_BOOL ("inhibit-message", inhibit_message,
-              doc:  /* Non-nil means calls to `message' are not displayed.
-They are still logged to the *Messages* buffer.
+  DEFVAR_LISP ("inhibit-message", Vinhibit_message,
+              doc:  /* Non-nil means suppress display of `message' text.
+The messages are still logged to the *Messages* buffer.
+If the value is `all', also suppress clearing the echo-area when
+the `message' function is called with an empty or nil argument.
 
 Do NOT set this globally to a non-nil value, as doing that will
 disable messages everywhere, including in I-search and other
 places where they are necessary.  This variable is intended to
 be let-bound around code that needs to disable messages temporarily. */);
-  inhibit_message = false;
+  Vinhibit_message = Qnil;
 
   message_dolog_marker1 = Fmake_marker ();
   staticpro (&message_dolog_marker1);

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 30 Mar 2025 02:45:57 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Colascione <dancol <at> dancol.org>
>> Date: Tue, 25 Mar 2025 14:58:35 -0400
>> 
>> 
>> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
>> the echo area.  I'd expect the semantic of inhibit-message to be
>> preventing all visible side effects of message --- not just some
>> of them.
>
> We need to preserve the current meaning of t as the value of
> inhibit-message, to avoid backward-incompatible changes.  So I added a
> third value to mean suppress clearing of the echo-area as well.  Does
> the patch below look right?

Normally I'm all for backwards compatibility --- but do you really think
there are people relying on inhibit-message t clearing the echo area?
On purpose?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 30 Mar 2025 10:48:16 +0300

> From: Daniel Colascione <dancol <at> dancol.org>
> Cc: 77257 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 02:45:57 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Daniel Colascione <dancol <at> dancol.org>
> >> Date: Tue, 25 Mar 2025 14:58:35 -0400
> >> 
> >> 
> >> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
> >> the echo area.  I'd expect the semantic of inhibit-message to be
> >> preventing all visible side effects of message --- not just some
> >> of them.
> >
> > We need to preserve the current meaning of t as the value of
> > inhibit-message, to avoid backward-incompatible changes.  So I added a
> > third value to mean suppress clearing of the echo-area as well.  Does
> > the patch below look right?
> 
> Normally I'm all for backwards compatibility --- but do you really think
> there are people relying on inhibit-message t clearing the echo area?
> On purpose?

How can we possibly know?  Clearing of the echo-area is not exactly
the same as displaying a message; the result of not clearing is to
leave the previous echo-area text on display intact, and how can we
know whether this behavior will surprise or annoy?  Maybe someone
binds inhibit-message non-nil because they want to see an empty
echo-area?

On top of that, clearing of the echo-area is done in many more places
than just when calling 'message' itself.

Call me a coward...

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: dancol <at> dancol.org, Stefan Kangas <stefankangas <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Andrea Corallo <acorallo <at> gnu.org>
Cc: 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 30 Mar 2025 11:47:14 +0300

> Cc: 77257 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 10:48:16 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Daniel Colascione <dancol <at> dancol.org>
> > Cc: 77257 <at> debbugs.gnu.org
> > Date: Sun, 30 Mar 2025 02:45:57 -0400
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> From: Daniel Colascione <dancol <at> dancol.org>
> > >> Date: Tue, 25 Mar 2025 14:58:35 -0400
> > >> 
> > >> 
> > >> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
> > >> the echo area.  I'd expect the semantic of inhibit-message to be
> > >> preventing all visible side effects of message --- not just some
> > >> of them.
> > >
> > > We need to preserve the current meaning of t as the value of
> > > inhibit-message, to avoid backward-incompatible changes.  So I added a
> > > third value to mean suppress clearing of the echo-area as well.  Does
> > > the patch below look right?
> > 
> > Normally I'm all for backwards compatibility --- but do you really think
> > there are people relying on inhibit-message t clearing the echo area?
> > On purpose?
> 
> How can we possibly know?  Clearing of the echo-area is not exactly
> the same as displaying a message; the result of not clearing is to
> leave the previous echo-area text on display intact, and how can we
> know whether this behavior will surprise or annoy?  Maybe someone
> binds inhibit-message non-nil because they want to see an empty
> echo-area?
> 
> On top of that, clearing of the echo-area is done in many more places
> than just when calling 'message' itself.
> 
> Call me a coward...

That said, if everyone else (CC'ed) think I'm too cautious, I will
make t inhibit clearing the echo-area as well.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andrea Corallo <acorallo <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>,
 77257 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 30 Mar 2025 09:42:49 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 77257 <at> debbugs.gnu.org
>> Date: Sun, 30 Mar 2025 10:48:16 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>> > From: Daniel Colascione <dancol <at> dancol.org>
>> > Cc: 77257 <at> debbugs.gnu.org
>> > Date: Sun, 30 Mar 2025 02:45:57 -0400
>> > 
>> > Eli Zaretskii <eliz <at> gnu.org> writes:
>> > 
>> > >> From: Daniel Colascione <dancol <at> dancol.org>
>> > >> Date: Tue, 25 Mar 2025 14:58:35 -0400
>> > >> 
>> > >> 
>> > >> (let ((inhibit-message t)) (message "blah")) has the effect of clearing
>> > >> the echo area.  I'd expect the semantic of inhibit-message to be
>> > >> preventing all visible side effects of message --- not just some
>> > >> of them.
>> > >
>> > > We need to preserve the current meaning of t as the value of
>> > > inhibit-message, to avoid backward-incompatible changes.  So I added a
>> > > third value to mean suppress clearing of the echo-area as well.  Does
>> > > the patch below look right?
>> > 
>> > Normally I'm all for backwards compatibility --- but do you really think
>> > there are people relying on inhibit-message t clearing the echo area?
>> > On purpose?
>> 
>> How can we possibly know?  Clearing of the echo-area is not exactly
>> the same as displaying a message; the result of not clearing is to
>> leave the previous echo-area text on display intact, and how can we
>> know whether this behavior will surprise or annoy?  Maybe someone
>> binds inhibit-message non-nil because they want to see an empty
>> echo-area?
>> 
>> On top of that, clearing of the echo-area is done in many more places
>> than just when calling 'message' itself.
>> 
>> Call me a coward...
>
> That said, if everyone else (CC'ed) think I'm too cautious, I will
> make t inhibit clearing the echo-area as well.

Yep. Looking forward to seeing what others think. I hear what you're
saying and would ordinarily agree, but in this specific case:

1. a plain reading of the inhibit-message documentation suggests that it
inhibits all UI effects of message, and I'm not the only one to
think so, and

2. the actual behavior just doesn't seem useful. Who *wants* the message
area cleared but not filled? If I want to clear the message area, I can
do it myself with (message nil).

Dunno. Just seems unlikely to me that people are intentionally relying
on current behavior. They might be doing so by accident, but that's a
bug, and we might as well flush out bugs.

BTW, shouldn't message' doc string mention inhibit-message?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: acorallo <at> gnu.org, stefankangas <at> gmail.com, 77257 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 30 Mar 2025 17:39:25 +0300

> From: Daniel Colascione <dancol <at> dancol.org>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  Stefan Monnier
>  <monnier <at> iro.umontreal.ca>,  Andrea Corallo <acorallo <at> gnu.org>,
>   77257 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 09:42:49 -0400
> 
> BTW, shouldn't message' doc string mention inhibit-message?

Cannot hurt.  Done on the emacs-30 branch, thanks.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andrea Corallo <acorallo <at> gnu.org>, dancol <at> dancol.org,
 Stefan Kangas <stefankangas <at> gmail.com>, 77257 <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 30 Mar 2025 11:01:33 -0400

> That said, if everyone else (CC'ed) think I'm too cautious, I will
> make t inhibit clearing the echo-area as well.

I'm in favor of the change.  I think it's very odd that (message "Haha")
ends up just clearing the echo area.  To me, the purpose of
`inhibit-message` is not to hide the messages that would be displayed
but to prevent those messages from interfering with other messages.


        Stefan

Message #52 received at 77257-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: acorallo <at> gnu.org, dancol <at> dancol.org, stefankangas <at> gmail.com,
 77257-done <at> debbugs.gnu.org
Subject: Re: bug#77257: inhibit-message should inhibit echo area clearing too
Date: Sun, 13 Apr 2025 10:47:14 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: dancol <at> dancol.org,  Stefan Kangas <stefankangas <at> gmail.com>,  Andrea
>  Corallo <acorallo <at> gnu.org>,  77257 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 11:01:33 -0400
> 
> > That said, if everyone else (CC'ed) think I'm too cautious, I will
> > make t inhibit clearing the echo-area as well.
> 
> I'm in favor of the change.  I think it's very odd that (message "Haha")
> ends up just clearing the echo area.  To me, the purpose of
> `inhibit-message` is not to hide the messages that would be displayed
> but to prevent those messages from interfering with other messages.

So we have two in favor and none against.  So I've now installed a
change that will disable clearing of echo-area messages when
inhibit-message is non-nil, and I'm closing this bug.

Previous Next

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