GNU bug report logs - #20563
Echo Area Disrupts Minibuffer Input

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20563 in the body.
You can then email your comments to 20563 AT debbugs.gnu.org in the normal way.

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

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

From: Michael Xavier <admin <at> michaelxavier.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Echo Area Disrupts Minibuffer Input
Date: Tue, 12 May 2015 10:40:34 -0700

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

I've encountered a rather frustrating UI issue as a recent Emacs convert
and would love to help think of a way to fix it. Bug #11172 references this
issue, but there was no comment or resolution.

The issue is that the echo area, which is used heavily from the message
function, shares screen real estate with the minibuffer. This normally
isn't a huge issue but if the user is actually using the minibuffer to
enter text, the prompt and the text they have entered thus far is
overwritten by some unrelated message and can only be wrestled back by
typing more.

The example I encounter frequently is doing a TAGS file search and hitting
TAB to complete. The tags system will fetch a completion and simultaneously
log a message that its reading the TAGS file which will completely
overwrite the completion.

A contrived example:

   emacs -Q
   M-: (run-with-timer 5 nil (lambda () (message "hello"))) RET
   M-x

The prompt will be overwritten by the message "hello".

I don't know what the best solution is. Two ideas I've had are:

1. Suppress messages to the echo area if the minibuffer is waiting on
input. The messages could display after the minibuffer stops waiting
(or not at all and they'll just log to *Messages*).

2. Divide the minibuffer (horizontally?) into the minibuffer proper
and the echo area. Maybe the division could only happen when there's
something in the echo area. Something tells me this approach is much
harder and more controversial.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Xavier <admin <at> michaelxavier.net>
Cc: 20563 <at> debbugs.gnu.org
Subject: Re: bug#20563: Echo Area Disrupts Minibuffer Input
Date: Tue, 12 May 2015 21:09:09 +0300

> Date: Tue, 12 May 2015 10:40:34 -0700
> From: Michael Xavier <admin <at> michaelxavier.net>
> 
> The example I encounter frequently is doing a TAGS file search and hitting TAB
> to complete. The tags system will fetch a completion and simultaneously log a
> message that its reading the TAGS file which will completely overwrite the
> completion.

But when it finishes reading the TAGS file, the completion is
re-displayed, right?  At least that's what I see here (and expect).

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

From: Michael Xavier <admin <at> michaelxavier.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20563 <at> debbugs.gnu.org
Subject: Re: bug#20563: Echo Area Disrupts Minibuffer Input
Date: Tue, 12 May 2015 11:18:44 -0700

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

I can't get it to reproduce right now. It may be a race condition, or maybe
its on a timer before it reverts to the minibuffer? I'm not sure.

On Tue, May 12, 2015 at 11:09 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Tue, 12 May 2015 10:40:34 -0700
> > From: Michael Xavier <admin <at> michaelxavier.net>
> >
> > The example I encounter frequently is doing a TAGS file search and
> hitting TAB
> > to complete. The tags system will fetch a completion and simultaneously
> log a
> > message that its reading the TAGS file which will completely overwrite
> the
> > completion.
>
> But when it finishes reading the TAGS file, the completion is
> re-displayed, right?  At least that's what I see here (and expect).
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Xavier <admin <at> michaelxavier.net>
Cc: 20563 <at> debbugs.gnu.org
Subject: Re: bug#20563: Echo Area Disrupts Minibuffer Input
Date: Tue, 12 May 2015 21:26:33 +0300

> Date: Tue, 12 May 2015 11:18:44 -0700
> From: Michael Xavier <admin <at> michaelxavier.net>
> Cc: 20563 <at> debbugs.gnu.org
> 
> I can't get it to reproduce right now. It may be a race condition, or maybe its
> on a timer before it reverts to the minibuffer? I'm not sure.

In general, code that displays intermittent messages should call

  (message nil)

once it's done displaying the message.  This will bring the minibuffer
contents (the completion in your example) back on screen again.  Code
that doesn't call 'message' like that when its message can be
discarded has a bug and should be reported here.

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

From: Glenn Morris <rgm <at> gnu.org>
To: 20563-done <at> debbugs.gnu.org
Subject: Re: bug#20563: Echo Area Disrupts Minibuffer Input
Date: Wed, 07 Dec 2016 15:25:22 -0500

Michael Xavier wrote:

> I can't get it to reproduce right now. It may be a race condition, or maybe
> its on a timer before it reverts to the minibuffer? I'm not sure.

18 months with no further information, so closing.

Previous Next

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