RE: messages override minibuffer input

[Drew Adams]

> > > If we put such messages at the end, that may cause the minibuffer
> > > to grow by a line.  Would you find that disturbing?
> > >
> > > If not, perhaps the thing to do is to put the message below the
> > > current input, always growing the minibuffer.  Or put the message
> > > above the minibuffer contents.  What would you think of that?
> >
> > Please don't do that. In general, let's try to keep echo-area
> > messages to one line. If they happen to be so long that they
> > wrap, so be it. So I'd request that we append without a newline.
>
> Maybe I misunderstand something here. I thought that the question
> was about messages placed at the end of a minibuffer line. So if the
> minibuffer takes already 70 display columns and the message requires
> another 70 columns I don't know how the message could fit into a
> standard window with 80 display columns unless the message is
> wrapped. In such a (standard?) case it would seem more natural to me
> to put the message completely into a new line.

It will wrap anyway if it is too long for the window size. That is, the
window width will automatically determine whether and where to visually add
a new line.

Different users have different width minibuffer windows. I, for instance,
use a standalone minibuffer frame that stretches all the way across my
display. On the display I'm using right now, it has room for 160 characters.
When I'm use other displays, it is narrower or wider; it always fills the
display width.

It is not a good idea to start inserting newlines in message text based on
assumptions of a standard (or any other) minibuffer width or height. Just
treat the echo area as a single long line, and let it wrap as needed.

That doesn't mean there could never be newlines in the echo area under any
circumstances. I'm just saying that there is no good reason to add them for
no good reason, and based on a window-size assumption.