Re: Minibuffer positioned at a location other than the bottom of the frame?

[martin rudalics]

>> I doubt that "Positioning the minibuffer to the top of the frame" would
>> be "much easier"
>
> "Much easier" than positioning it dynamically below the selected
> window, or some other dynamic positioning.  I'm sure you will agree.

Logistically, yes.  But not when it comes to handling the visual
appearance.  I recall that I once tried to resize a frame's windows
proportionally when resizing the echo area.  You were not amused.

>> When Emacs enlarges the minibuffer window it then has
>> to move all windows beneath down by the number of lines the minibuffer
>> window has been enlarged.
>
> Why "all"? why not just the next window below the minibuffer?  That's
> what we do now: we resize only the window immediately above the
> minibuffer.  Right?

When you have two side-by-side windows on the top of a frame you have to
resize them both.  Just as we do now when there are two side-by-side
windows right above the echo area.  If such windows have fixed height or
are too small, we have to resize other windows as well.

>> To not make these windows' texts move down
>> accordingly (which would constitute a very unpleasent visual experience)
>> we would have to try to change these windows' start positions and
>> restore them accordingly when shrinking the minibuffer window back.
>
> That's probably true, but we need to redisplay that window anyway, so
> we can choose a different window-start while we are at that.

But there's a great visual difference when the entire contents of a
window move on screen instead of when just some of its bottom lines get
hidden or revealed.

>> Obviously, with point near the top of the window or varying line heights
>> such an attempt might become very tricky or even impossible.
>
> I don't see why it would be impossible.

To keep the text exactly in place, we would possibly have to start a
window with a partly obscured line.  IIUC we could do that but there are
no functions for it (have the iterator step backward, calculate how much
to show of the first line of a window).  So it's "impossible" with our
current means.

> And in any case, this will be
> an opt-in feature, so those who don't like the result will not use it.
>
>> Putting the minibuffer window below some arbitrary (maybe even internal)
>> window of a frame would not run into such difficulties.
>
> I'm okay with that as well, if someone figures out how to implement
> it.

A first step would be to allow not showing echo area and minibuffer at
all and, in case of a user interaction, show them just in the selected
window or on a separate frame as a fallback.  And, obviously, create a
minibuffer window on the fly whenever and wherever it's needed.

Note that while some comments in our sources still consider it vital
that the minibuffer window is always visible, in practice this has no
importance since you can always shrink a frame to its title bar (which
for a GUI might be the most convenient position for showing echo area
and minibuffer anyway).

martin