Re: Emphasizing the top of the frame

[martin rudalics]

> So we both are happy with a minibuffer that can
> overlap portions of the main frame.  My version,
> tries to preserve as much of classic minibuffer
> behavior as possible.  That is why I do not use
> auto-hide.  And if I do not auto hide then I need
> to find a way to keep the minibuffer visible at all
> times and, when not expanded, avoid overlapping
> any important content in the main frame.  Which
> leads to overlaying the menu bar.

I noticed that your 'resize-mini-frames' function preserves the width of
the frame, something which should be done by default.  But I'm always
reluctant to change established defaults, no matter how silly they are.

>> Nowadays you could also try overlaying the tabbar.
>
> Great suggestion.  That menu bar was outside of
> emacs' managed space, leading me to eschew
> the child window mechanism.  Not so the tab bar!
> I have switched to overlapping the tab bar and
> made the minibuffer frame a child of the parent
> window.  A very nice simplification.  I set position
> to (0, 0) at creation and never update again.  Plus
> I removed all vestiges of restacking and hooking
> move-frame-functions.  Finally my two frames
> move and resize as a unit.

You might consider experiencing with the 'keep-ratio' parameter of the
child frame.  The idea is that if this parameter is t, the child frame
automatically resizes along with its parent.

>>   My own modified version
>> of Emacs can show minibuffer and/or echo area combined/separately on
>> bottom and/or top of a frame or in an arbitrary window and hide them
>> away when they are empty.
>
> Did you just say that one can position the echo
> area separate from the minibuffer?  Where is
> that explained?

I've been confusing you.  My minibuffer in a child frame solution which
is similar to yours lives in a self-contained package I use ever since
Emacs 26.  The "modified version" doing what I sketched above lives in
my local changes to the Emacs redisplay and window management code and
is explained only locally there.

>> The one restriction that remains is the one I
>> cited on top of my mail - resizing any of these windows will resize at
>> least one other window.
>
> I am not able to make sense of that statement.
> Are you saying that when a separate minibuffer
> frame resizes some other window on another
> frame resizes?  I think that I would find such
> behavior disconcerting.

I meant that when the minibuffer is _not_ on a frame of its own,
resizing it will resize at least one other window on the same frame.
You have to keep this in mind if you want to display, for example, the
minibuffer on the top of a TTY frame.

martin