Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Drew Adams]

> > Would doing something like what eldoc-minibuffer-message does
> > possibly be a good solution?  It seems to me that this is safer than the
> > current situation, as it does not fiddle with the minibuffer contents.
> > If so, what do you (and others) think of the following...
> 
> I personally feel that moving echo-area messages to the mode line is
> too drastic a change to make it by default, and certainly in a minor
> release.  But let's hear wjat others think, and what other ideas will
> be brought up.

As I mentioned, the basic problem is due to sharing
the same area between minibuffer and echo area.

Ultimately, a good solution requires being able to
see both at the same time.  Juggling their content
wrt time, while sharing the same space, won't take
care of the problem in general.

The same problem will exist if you move output
(`message' echoes) to the mode-line: you won't be
able to see the mode-line info and the message at
the same time.

For simple interactions, there's no problem.  The
problem arises for more complex interactions, and
for that no "solution" that always uses the same
space can possibly be a real solution.

Do I think that using the mode-line makes more
sense than forcing `message' output to, in effect,
use `minibuffer-message', i.e., putting it at the
end of your minibuffer input?

Yes, probably the mode-line is usually better
than that, at least.  When you're responding to a
prompt, anything that's not directly related to
the prompt-&-response interaction doesn't belong
in the input area.

But we do need a real solution, assuming that we
think that bug #38457 is serious enough.  The fix
accepted for that bug isn't healthy, as I've said.

A real solution provides separate areas for echo
(output) and minibuffer input.

We could reserve some new area for echoing.  Or we
could choose to echo in a separate area only when
needed.  E.g., we might use the same area for echo
and minibuffer whenever there's no conflict (no
overlap in time), and show echoes in some other
place (e.g. pop-up) in the rarer cases when needed.

"Pop up" here could mean temporarily overwriting
the mode-line, as Gregory suggested.  Or it could
temporarily overwrite the last line(s) of the
window content. Or it could mean popping up a
window or frame.  Or...

The point is this:

1. For simple interactions, there's no problem.
   Most of the time there's no overlap in time
   between output and input.

2. For complex interactions, i.e., when output and
   input overlap in time, NO solution that shares
   the same space really takes care of the problem.

   At best, we end up showing the output for some
   brief period of time, and then return to showing
   the input.  And that doesn't really satisfy bug
   #38457.

3. To deal with #2, we need to use some separate
   space for output (echoes).  We could either (a)
   always have two separate spaces (e.g. a new area
   for `message' etc. echoes) or (b) show echoes in
   some other area only when needed ("pop up").

4. If we do choose to overwrite (hide) something
   in order to show output in a temporary way, then
   IMO it's better to overwrite/hide some buffer
   text, or the mode-line, than it is to do that
   to minibuffer input.

   The last thing we should hide or interfere with
   is the immediate user interaction (responding to
   a prompt by providing text input).

#4 is a personal opinion.  The rest should hopefully
be considered less controversial.
___


https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38457#104

(Completely ignored there.)