GNU bug report logs -
#77257
inhibit-message should inhibit echo area clearing too
Previous Next
Full log
View this message in rfc822 format
> 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.
This bug report was last modified 96 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.