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

[Drew Adams]

> > 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.
> 
> That's obviously a problem that will exist in any possible solution to
> that problem: the message will hide something.  

Not if the area used for echoes (output) is
separate from the area used for the minibuffer
(prompt and input).

Well yes, a previous message in the output area
is overwritten.  But it's logged in *Messages*.
The point here is to separate input and output
areas, so output doesn't hide prompt or input.

> The question is then: what
> is the "something" that can be hidden with the least possible risk?  IMO
> the mode-line is, in this context, the least important element, and it can
> be temporarily right-shifted.  Eldoc does this, too.

I said the same thing regarding importance, if
the candidates are only the mode-line and the
minibuffer.

But there are other possibilities.  (I mentioned
using the last line(s) of some window as one.)

But we need not overwrite - or displace at all,
if we show the output in its own area - at least
when there would otherwise be a conflict with the
minibuffer/echo area.  I mentioned "popping up"
such an output area as needed.

Shifting existing stuff around could be distracting
or annoying for some users.  A dedicated area for
output wouldn't have that problem, but it would
sacrifice real estate when nothing is being output.

Whatever we do, it would be good to let users get
different behavior as an option. 

> > 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.
> 
> That's exactly what my proposed solution does.  The same area is used when
> there's no conflict, and the "pop-up" uses the space on the left of the
> mode-line, which is temporarily right-shifted.

Yes, I know.  And I mentioned that I prefer that
to appending output to the minibuffer input.

But that's one of the half measures.  It still
occludes or displaces something.  If the right
end of the mode-line gets truncated because the
content is right-shifted, then the truncated
part is "lost" (hidden).

There are half measures and full measures for
the general problem.  The use-the mode-line
half-measure is better than the one that's been
put in place for Emacs 27, IMO.

> > "Pop up" here could mean temporarily overwriting
> > the mode-line, as Gregory suggested.
> 
> No, the mode-line is not temporarily overwritten, it is temporarily
> right-shifted.  Usually (when the message is not too long) the leftmost
> part of the mode-line remains visible.

Got it.  (I meant that, but spoke imprecisely.)

IMO we can do still better.  But your suggestion
beats what we have now.  And it beats what we had
before Emacs 27 - at least in terms of not losing
or obscuring user input.

[IMO what we had before Emacs 27 is better than
what we have now, but on n'arrete pas le progres.]