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

[Drew Adams <drew.adams@oracle.com>]

> >> > 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.
> 
> For me, as a blind braille display user, using the same space in the
> *only* solution that works.  I only have one line of text output.  Which
> area of the screen this line represents is mostly controlled by the
> cursor location.  In essence, my attention can only be focused at one
> place at a time.  Magically showing messages in some other location will
> not work for me at all, I will just miss them.  I am fully aware that I am
> not
> representative for all Emacs users, but your wording seems to indicate
> that you are neglecting the fact that there might be use cases
> which do not work the way you imagine.
> 
> If your suggestion gets implemented, please dont forget to put it
> behind a configuration flag.  It will be the first thing I need to turn
> off in .emacs.

Don't worry; I think there's little chance that what
I suggested will be done.

And to be clear, I am in favor of the behavior we had
before the recent change to automatically sticking
output messages at the end of the minibuffer, instead
of in the echo area.

Minibuffer and echo area are in the same space on the
screen, so both are presumably OK for your use.

But I prefer that messages unrelated to the current
minibuffer interaction (i.e., messages from `message')
be shown in the echo area, and that _only_ messages
related to the minibuffer interaction be appended to
minibuffer input (i.e., as from `minibuffer-message').
Code should be able to use either the echo area or the
end of the minibuffer, to show output when the
minibuffer is active.

My point was only this:

IF people are worried about not noticing some messages
that come out of the blue from somewhere while the
minibuffer is active (because the minibuffer occludes
the echo area), then a proper solution would be to use
a different area for output (messages) than what is
used for input.

The general problem of such unnoticed messages exists.
I'm not particularly bothered by it, personally.  My
point is only that the solution chosen isn't a good
one.  A real solution for dealing with asynchronous
messages calls for separating the two (inputs and
outputs) spatially.

I'm not sure why exactly that would be problematic
for you, as focus does change in Emacs in other ways
anyway.  But I believe you.  And I appreciate your
input on this.  And yes, unfortunately, I hadn't
thought of how blind braille display users would
have to deal with such things.

A real solution needs to take your use cases into
account properly.  Thanks for your input about this.