Re: Emphasizing the top of the frame

[martin rudalics]

> Indeed.  And I like it.  Except that some packages assume
> upward growth and so position the prompt at the bottom of
> the frame, whereas in my case the more natural position
> would be at the top.

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.

> I suspect that if I used a child frame then at least some
> of the glitches that I encounter would disappear.  The
> reason that I cannot use a child frame is that doing so
> constrains the minibuffer frame to reside within the space
> managed by emacs.  As such it would be guaranteed to
> hide something.

Right.  But IIUC your minibuffer frame also hides the menubar and, when
it grows (downwards), will hide other parts on top of the Emacs frame
too.  And didn't you claim initially that hiding is a feasible strategy,
something on which I agree because I do it myself.

> It is interesting that you mention that your separate
> minibuffer frame "rarely has let [you] down".  From
> that I conclude that you too know that the separate
> minibuffer experience is not as polished as that with
> a traditional minibuffer.

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.

> To avoid visible flashing and resizing during frame
> creation, I initially marked the frame invisible, making
> it visible at the last moment once all setup was done.
> Part of the setup was an attempt to get the main and
> the minibuffer frames into a proper stacking relationship.
> It took a night's sleep and a shower for me to realize
> that perhaps restacking an invisible frame might not
> be supported.

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.

so you have to restack the minibuffer window also, for example, after
you deiconified the underlying normal frame.  This is a problem child
frames solve automagically.

> (I am a C++ compiler writer by trade
> and gui concepts are quite foreign.  I am having to
> learn as I go. :-)
>
>> (add-hook
>>    'move-frame-functions
>>    (lambda (frame)
>>      (message "Frame %s moved to %s" frame (frame-position frame))))
>>
>> If you don't see them, please tell us which toolkit and window manager
>> you use.
>
> I had tried essentially that same experiment on my
> own.  Just to be sure, I retried with your text verbatim.
> Nothing shows up in *Messages*, neither with my
> init.el loaded nor when I run emacs -Q.
>
> I am on vanilla Ubuntu 21.10.
> I build emacs regularly from the tip thusly:
>
> ./configure \
[...]
>    --with-pgtk \

I think that's the culprit.  You should use --with-pgtk if and only if
you use the Wayland backend.  If the problem persists even with a normal
X build, then the window manager might interfere.

[...]

> As I stated earlier, one goal is to demonstrate an
> attractive layout and experience.  Were this part
> of core emacs, a minibuffer at the top of the frame
> would never overlay the title bar.  Overlaying the
> menubar, by contrast, places the minibuffer visually
> in a very natural position.

Nowadays you could also try overlaying the tabbar.

>>   > I hope that the existence of mbmb prompts owners
>>   > of minibuffer-resizing packages to support growth
>>   > downward in addition to today's growth upward.
>>   > (Could we standardize a frame parameter to record
>>   > this direction?)
>>
>> Do you mean we should resize the frame whenever the minibuffer window
>> changes size?  That sounds hardly feasible.
>
> No.  Not at all.  I mean various packages assume
> that, in a multi-line minibuffer layout, the persistent
> minibuffer line is at the bottom and any additional
> space has been added above.  Similarly, there are
> packages that assume adjacency of the minibuffer
> and the completions buffer is achieved by having
> the completions buffer sit above the minibuffer.

OK.  But what would you change in core Emacs?  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.  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.

martin