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

Previous Next

Full log

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)]

Previous Next

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