bug#20563: Echo Area Disrupts Minibuffer Input

bug#20563: Echo Area Disrupts Minibuffer Input

[Michael Xavier]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1995 bytes --]

bug#20563: Echo Area Disrupts Minibuffer Input

[Eli Zaretskii]

> Date: Tue, 12 May 2015 10:40:34 -0700
> From: Michael Xavier <admin@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).

bug#20563: Echo Area Disrupts Minibuffer Input

[Michael Xavier]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

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@gnu.org> wrote:

> > Date: Tue, 12 May 2015 10:40:34 -0700
> > From: Michael Xavier <admin@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).
>

[-- Attachment #2: Type: text/html, Size: 1110 bytes --]

bug#20563: Echo Area Disrupts Minibuffer Input

[Eli Zaretskii]

> Date: Tue, 12 May 2015 11:18:44 -0700
> From: Michael Xavier <admin@michaelxavier.net>
> Cc: 20563@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.

bug#20563: Echo Area Disrupts Minibuffer Input

[Glenn Morris]

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.