Re: Emphasizing the top of the frame

[John Yates <john@yates-sheets.org>]

Hi Martin,

> Please don't ignore one important design principle here: The windows
> within an Emacs frame, including the minibuffer window, do not overlap.
> Hence, enlarging one window inevitably will shrink another window.  If
> you want overlapping windows, you have to use child frames.

Of course.  I am doing nothing to the main window.
My fundamental shift is to a minbuffer frame that
lives near the top of the frame and, when it grows,
does so by overlapping portions of topmost windows.
Because such behavior violates emacs orthodoxy
I feel that I need to present a working example.

> It is occasionally problematic when switching focus between two or more
> normal frames and a minibuffer interaction is going on and when trying
> to quit the minibuffer.  And since my minibuffer frame auto-hides when
> I don't need it, I have to turn off all sorts of things Emacs wants to
> show in the echo area that I never want to see.

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.

> The Elisp manual warns that
>
>    Note that the effect of restacking will only hold as long as neither
>   of the involved frames is iconified or made invisible.

Clearly I missed that (but see below).

>  >    --with-pgtk \
>
> I think that's the culprit.

Thanks.  Removed.

> 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.

> OK.  But what would you change in core Emacs?

Let me defer answering that question until I have
a more complete mockup.

>  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?

Clearly, your package accommodates many
more set-ups than I envision.  My goal is to
preserve the minibuffer-per-frame model that
most users know.  (That works for me because
I live primarily within a single maximized emacs
frame.)

> 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.

Thanks for multiple very helpful suggestions.

/john