Emphasizing the top of the frame

Emphasizing the top of the frame

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

I have recently switched to a 30" 2560x1600 screen.  In emacs I love having
3 side-by-side 100+ column windows.

What I do not love is the tension between the height of the screen and
emacs' bottom bias (mini-buffer at the bottom of its frame, mode-line at
the bottom of each window).  This contrasts with the rest of current window
layout conventions which place title information at the top of
window/frames.

I really would like to be able to specify that
* the mini-buffer should be positioned at the top of the inner-frame
* the mode-line should be the very first line in a window, rather than the
last

Since this is a personal itch I am willing to starting poking at the code
on my own.  That said this will be my first foray into the emacs .c
sources.  Pointers and/or suggested lines of attack very welcome.

/john

[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

Re: Emphasizing the top of the frame

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 211 bytes --]

On 2016-10-25 13:53, John Yates wrote:
> * the mode-line should be the very first line in a window, rather than the last

You could simply set header-line-format to mode-line-format, I think.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: Emphasizing the top of the frame

[Drew Adams]

This does not meet your request completely or exactly, but you can use a standalone minibuffer frame, and place it anywhere you like, including at the top of your display.

Re: Emphasizing the top of the frame

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Tue, 25 Oct 2016 13:53:32 -0400
> 
> I really would like to be able to specify that
> * the mini-buffer should be positioned at the top of the inner-frame
> * the mode-line should be the very first line in a window, rather than the last
> 
> Since this is a personal itch I am willing to starting poking at the code on my own. That said this will be my
> first foray into the emacs .c sources. Pointers and/or suggested lines of attack very welcome.

The relevant places to look are xdisp.c, dispnew.c, and dispextern.h.
IOW, the Emacs display engine.  It currently _knows_ that the
minibuffer is at bottom and that the mode line is the last screen line
of any window.  See, for example, the macro MATRIX_MODE_LINE_ROW in
dispextern.h.

Don't hesitate to ask more questions: this might sound like a simple
project, but it can be much harder if you don't know where to look.

Good luck, and thanks in advance for working on this.

Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Tue, 25 Oct 2016 21:27:23 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> The relevant places to look are xdisp.c, dispnew.c, and dispextern.h.
> IOW, the Emacs display engine.  It currently _knows_ that the
> minibuffer is at bottom and that the mode line is the last screen line
> of any window.

That was somewhat inaccurate: the fact that the minibuffer window is
at bottom is coded in frame.c:make_frame, where the frame's window
tree is set such that the minibuffer window is on the 'next' pointer
from the frame's root window.  Switching the order shouldn't be hard,
but I'd like Martin's opinion on how many things this could break.

Re: Emphasizing the top of the frame

[martin rudalics]

 >> The relevant places to look are xdisp.c, dispnew.c, and dispextern.h.
 >> IOW, the Emacs display engine.  It currently _knows_ that the
 >> minibuffer is at bottom and that the mode line is the last screen line
 >> of any window.
 >
 > That was somewhat inaccurate: the fact that the minibuffer window is
 > at bottom is coded in frame.c:make_frame, where the frame's window
 > tree is set such that the minibuffer window is on the 'next' pointer
 > from the frame's root window.  Switching the order shouldn't be hard,
 > but I'd like Martin's opinion on how many things this could break.

Does the display engine anywhere rely on that order?  The frame/window
code doesn't and conceptually should even tolerate the next window of
the root window being nil all the time.

I would start by assigning the appropriate pixel_top and top_line values
for root and minibuffer window (grow_mini_window, shrink_mini_window,
resize_frame_windows, make_frame, Fresize_mini_window_internal,
init_xdisp seem affected at least) and look what happens.

Note, however, that enlarging the minibuffer window currently tries to
"adjust the trailing edge" of the root window (see that comment in
‘window--resize-root-window-vertically’

       ;; When shrinking the root window, emulate an edge drag in order
       ;; to not resize other windows if we can avoid it (Bug#12419).

and the bug mentioned there for why that is important).

No routine for adjusting "the leading edge" of a window exists.  So you
either have to write such a routine (it's not hard to write but probably
hard to integrate into the current framework of resizing routines) or
use the resize-windows-proportionally approach (with the consequence
that enlarging the minibuffer window will shrink all vertically stacked
subwindows of the root window proportionally and maybe readjust their
start positions).

martin

Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Wed, 26 Oct 2016 10:10:32 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  >> The relevant places to look are xdisp.c, dispnew.c, and dispextern.h.
>  >> IOW, the Emacs display engine.  It currently _knows_ that the
>  >> minibuffer is at bottom and that the mode line is the last screen line
>  >> of any window.
>  >
>  > That was somewhat inaccurate: the fact that the minibuffer window is
>  > at bottom is coded in frame.c:make_frame, where the frame's window
>  > tree is set such that the minibuffer window is on the 'next' pointer
>  > from the frame's root window.  Switching the order shouldn't be hard,
>  > but I'd like Martin's opinion on how many things this could break.
> 
> Does the display engine anywhere rely on that order?

Not that I've seen (by looking at all users of FRAME_MINIBUF_WINDOW),
but I could miss something.  And there is init_xdisp, which you
mentioned, that hardcodes the top coordinate of the minibuffer window.
But see below.

> The frame/window code doesn't and conceptually should even tolerate
> the next window of the root window being nil all the time.

But doesn't the frame's window tree have to start with the root
window?  If it does, then how do we make the minibuffer window be its
"prev"?

> Note, however, that enlarging the minibuffer window currently tries to
> "adjust the trailing edge" of the root window (see that comment in
> ‘window--resize-root-window-vertically’
> 
>        ;; When shrinking the root window, emulate an edge drag in order
>        ;; to not resize other windows if we can avoid it (Bug#12419).
> 
> and the bug mentioned there for why that is important).

And that is at least one implicit dependency on this in the display
engine.  I wonder how many more are there.

IME, eventually there's no other way but to make the changes in the
places you find, fire up Emacs, see what stops working, and debug and
fix each feature that becomes broken.

We probably should have a variable that tells where the minubuffer
window appears, and code which needs to know needs to examine its
value.

Thanks.

Re: Emphasizing the top of the frame

[martin rudalics]

 >> Does the display engine anywhere rely on that order?
 >
 > Not that I've seen (by looking at all users of FRAME_MINIBUF_WINDOW),

I thought about some implicit ordering within the TTY display code.
Critical uses would be that of the next field of the root window - not
easy to spot, though (window.c, which has the greatest share of them,
can be disregarded, however).

 > but I could miss something.  And there is init_xdisp, which you
 > mentioned, that hardcodes the top coordinate of the minibuffer window.

If we only talk about _coordinates_ I see no problem - these have to be
adjusted anway.

 > But see below.
 >
 >> The frame/window code doesn't and conceptually should even tolerate
 >> the next window of the root window being nil all the time.
 >
 > But doesn't the frame's window tree have to start with the root
 > window?  If it does, then how do we make the minibuffer window be its
 > "prev"?

Both, a frame's root and minibuffer window, are accessible directly.
There is no reliance on the prev and next fields of these windows, with
one exception: The `window-tree' function would have to be modified
accordingly if we decided to swap the root and minibuffer windows'
order.  But that function should not be used anyway.  The more important
function is ‘walk-window-tree’ and that one accesses the minibuffer via
‘minibuffer-window’.

 >> Note, however, that enlarging the minibuffer window currently tries to
 >> "adjust the trailing edge" of the root window (see that comment in
 >> ‘window--resize-root-window-vertically’
 >>
 >>         ;; When shrinking the root window, emulate an edge drag in order
 >>         ;; to not resize other windows if we can avoid it (Bug#12419).
 >>
 >> and the bug mentioned there for why that is important).
 >
 > And that is at least one implicit dependency on this in the display
 > engine.  I wonder how many more are there.

Where do you see an "implicit dependency" here?

 > IME, eventually there's no other way but to make the changes in the
 > places you find, fire up Emacs, see what stops working, and debug and
 > fix each feature that becomes broken.
 >
 > We probably should have a variable that tells where the minubuffer
 > window appears, and code which needs to know needs to examine its
 > value.

An option, yes.  Or a special value `top' for the minibuffer frame
parameter.

martin

Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Wed, 26 Oct 2016 14:31:18 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: john@yates-sheets.org, emacs-devel@gnu.org
> 
>  >> Does the display engine anywhere rely on that order?
>  >
>  > Not that I've seen (by looking at all users of FRAME_MINIBUF_WINDOW),
> 
> I thought about some implicit ordering within the TTY display code.

The TTY display code is frame-based, and for a good reason.  IOW, it
updates the entire frame, not each window separately.

>  > But doesn't the frame's window tree have to start with the root
>  > window?  If it does, then how do we make the minibuffer window be its
>  > "prev"?
> 
> Both, a frame's root and minibuffer window, are accessible directly.
> There is no reliance on the prev and next fields of these windows

There are at least two functions in the display engine that walk the
window tree, so I'm not sure what you mean by "no reliance on prev and
next").

>  >> Note, however, that enlarging the minibuffer window currently tries to
>  >> "adjust the trailing edge" of the root window (see that comment in
>  >> ‘window--resize-root-window-vertically’
>  >>
>  >>         ;; When shrinking the root window, emulate an edge drag in order
>  >>         ;; to not resize other windows if we can avoid it (Bug#12419).
>  >>
>  >> and the bug mentioned there for why that is important).
>  >
>  > And that is at least one implicit dependency on this in the display
>  > engine.  I wonder how many more are there.
> 
> Where do you see an "implicit dependency" here?

That AFAIU the display engine knows that it can resize the minibuffer
window by moving the lower edge of the root window.

>  > We probably should have a variable that tells where the minubuffer
>  > window appears, and code which needs to know needs to examine its
>  > value.
> 
> An option, yes.  Or a special value `top' for the minibuffer frame
> parameter.

Maybe both.  An option is easier to customize than a frame parameter.

Re: Emphasizing the top of the frame

[martin rudalics]

 > The TTY display code is frame-based, and for a good reason.  IOW, it
 > updates the entire frame, not each window separately.

But for that it (1) has to "walk the window tree as well" and (2) know
where to draw the minibuffer window.

 >> Both, a frame's root and minibuffer window, are accessible directly.
 >> There is no reliance on the prev and next fields of these windows
 >
 > There are at least two functions in the display engine that walk the
 > window tree,

Which ones are that?

 > so I'm not sure what you mean by "no reliance on prev and
 > next").

I meant the prev and next fields of the root window and the minibuffer
window.  The next field leading from the root window to the minibuffer
window is conceptually redundant - but might be still in use somewhere
as, for example, in ‘window-tree’.

The window tree proper is the tree rooted at the root window.  The root
window and the minibuffer window of a "normal" frame do not form a tree
- they have no common ancestor.

 > That AFAIU the display engine knows that it can resize the minibuffer
 > window by moving the lower edge of the root window.

All the display engine should know is that it can resize the minibuffer
up to a certain extent.  Deciding who pays for that operation and to
what extent should be left to the window code.  Think of a one line high
window bordering the minibuffer window.

martin

Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Wed, 26 Oct 2016 16:23:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org, john@yates-sheets.org
> 
>  > The TTY display code is frame-based, and for a good reason.  IOW, it
>  > updates the entire frame, not each window separately.
> 
> But for that it (1) has to "walk the window tree as well" and (2) know
> where to draw the minibuffer window.

No, it doesn't.  The window glyph matrices on TTY frames are actually
portions of the frame glyph matrix, so whenever a window's glyphs are
updated by xdisp.c, the corresponding glyphs of the frame are
automagically updated as well.

>  >> Both, a frame's root and minibuffer window, are accessible directly.
>  >> There is no reliance on the prev and next fields of these windows
>  >
>  > There are at least two functions in the display engine that walk the
>  > window tree,
> 
> Which ones are that?

redisplay_windows and hscroll_window_tree.  I now see that so do
mark_window_display_accurate, redisplay_mode_lines,
update_cursor_in_window_tree, and expose_window_tree.

>  > so I'm not sure what you mean by "no reliance on prev and
>  > next").
> 
> I meant the prev and next fields of the root window and the minibuffer
> window.  The next field leading from the root window to the minibuffer
> window is conceptually redundant - but might be still in use somewhere
> as, for example, in ‘window-tree’.

The functions listed above actually use the 'next' pointer when they
walk the window tree.

> The window tree proper is the tree rooted at the root window.  The root
> window and the minibuffer window of a "normal" frame do not form a tree
> - they have no common ancestor.

Maybe I'm missing something, but there's this fragment in make_frame:

  root_window = make_window ();
  rw = XWINDOW (root_window);
  if (mini_p)
    {
      mini_window = make_window ();
      mw = XWINDOW (mini_window);
      wset_next (rw, mini_window);
      wset_prev (mw, root_window);
      mw->mini = 1;
      wset_frame (mw, frame);
      fset_minibuffer_window (f, mini_window);
      store_frame_param (f, Qminibuffer, Qt);
    }

This seems to arrange for the minibuffer window to be the "next" of
the root window, no?

>  > That AFAIU the display engine knows that it can resize the minibuffer
>  > window by moving the lower edge of the root window.
> 
> All the display engine should know is that it can resize the minibuffer
> up to a certain extent.  Deciding who pays for that operation and to
> what extent should be left to the window code.  Think of a one line high
> window bordering the minibuffer window.

I thought you were saying that it knew more than that, but the last
time I looked at that code was long ago.

Re: Emphasizing the top of the frame

[martin rudalics]

 >> But for that it (1) has to "walk the window tree as well" and (2) know
 >> where to draw the minibuffer window.
 >
 > No, it doesn't.  The window glyph matrices on TTY frames are actually
 > portions of the frame glyph matrix, so whenever a window's glyphs are
 > updated by xdisp.c, the corresponding glyphs of the frame are
 > automagically updated as well.

Looks like changing the minibuffer position is harder for TTY frames.

 >>   > There are at least two functions in the display engine that walk the
 >>   > window tree,
 >>
 >> Which ones are that?
 >
 > redisplay_windows and hscroll_window_tree.  I now see that so do
 > mark_window_display_accurate, redisplay_mode_lines,
 > update_cursor_in_window_tree, and expose_window_tree.

As a matter of fact, there are a few more in window.c - foreach_window,
mark_window_cursors_off, window_set_before_size_change_sizes,
window_size_changed and get_leaf_windows.  So I suppose that John should
try hard to _not_ change the relative order of the root and minibuffer
window and hope that interchanging the coordinates (something he has to
do anyway) will suffice.

 >> The window tree proper is the tree rooted at the root window.  The root
 >> window and the minibuffer window of a "normal" frame do not form a tree
 >> - they have no common ancestor.
 >
 > Maybe I'm missing something, but there's this fragment in make_frame:
 >
 >    root_window = make_window ();
 >    rw = XWINDOW (root_window);
 >    if (mini_p)
 >      {
 >        mini_window = make_window ();
 >        mw = XWINDOW (mini_window);
 >        wset_next (rw, mini_window);
 >        wset_prev (mw, root_window);
 >        mw->mini = 1;
 >        wset_frame (mw, frame);
 >        fset_minibuffer_window (f, mini_window);
 >        store_frame_param (f, Qminibuffer, Qt);
 >      }
 >
 > This seems to arrange for the minibuffer window to be the "next" of
 > the root window, no?

Yes.  The root of the next tree, as it were.  Obviously, this next field
is convenient for walking the structure formed by the root tree and the
minibuffer window as your examples from the display engine show.

martin

Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Wed, 26 Oct 2016 19:56:07 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: john@yates-sheets.org, emacs-devel@gnu.org
> 
>  >> But for that it (1) has to "walk the window tree as well" and (2) know
>  >> where to draw the minibuffer window.
>  >
>  > No, it doesn't.  The window glyph matrices on TTY frames are actually
>  > portions of the frame glyph matrix, so whenever a window's glyphs are
>  > updated by xdisp.c, the corresponding glyphs of the frame are
>  > automagically updated as well.
> 
> Looks like changing the minibuffer position is harder for TTY frames.

I'm not sure.  I don't see any signs of that, but it's always possible
that I'm missing something.

> As a matter of fact, there are a few more in window.c - foreach_window,
> mark_window_cursors_off, window_set_before_size_change_sizes,
> window_size_changed and get_leaf_windows.  So I suppose that John should
> try hard to _not_ change the relative order of the root and minibuffer
> window and hope that interchanging the coordinates (something he has to
> do anyway) will suffice.

Isn't it a requirement that the "next" window shall be always below or
to the right of its "prev"?

Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Wed, 26 Oct 2016 21:40:46 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, john@yates-sheets.org
> 
> > Date: Wed, 26 Oct 2016 19:56:07 +0200
> > From: martin rudalics <rudalics@gmx.at>
> > CC: john@yates-sheets.org, emacs-devel@gnu.org
> > 
> >  >> But for that it (1) has to "walk the window tree as well" and (2) know
> >  >> where to draw the minibuffer window.
> >  >
> >  > No, it doesn't.  The window glyph matrices on TTY frames are actually
> >  > portions of the frame glyph matrix, so whenever a window's glyphs are
> >  > updated by xdisp.c, the corresponding glyphs of the frame are
> >  > automagically updated as well.
> > 
> > Looks like changing the minibuffer position is harder for TTY frames.
> 
> I'm not sure.

Btw, I'm not sure this is even desirable for TTY frames.  Does anyone
really run huge xterm windows on such large displays?

Re: Emphasizing the top of the frame

[Paul Eggert]

On 10/26/2016 11:51 AM, Eli Zaretskii wrote:
> Btw, I'm not sure this is even desirable for TTY frames.  Does anyone
> really run huge xterm windows on such large displays?
>
I don't, but I've seen other people do, who like the traditional tty 
feel. Also, I imagine there would be similar issues on large Linux consoles.

Re: Emphasizing the top of the frame

[Stefan Monnier]

>> Btw, I'm not sure this is even desirable for TTY frames.  Does anyone
>> really run huge xterm windows on such large displays?
> I don't, but I've seen other people do, who like the traditional tty
> feel. Also, I imagine there would be similar issues on large Linux consoles.

And in any case, if someone likes it this way in his large GUI frames,
he'll probably gets used to expecting the minibuffer and modelines at
the top, so he'll want them *always* at the top, whether the frame is
large or not, GUI or tty.


        Stefan

Re: Emphasizing the top of the frame

[martin rudalics]

 > Isn't it a requirement that the "next" window shall be always below or
 > to the right of its "prev"?

For the tree rooted at ‘frame-root-window’ it certainly is.  For the
‘frame-root-window’ / ‘minibuffer-window’ relationship hopefully not.

martin

Re: Emphasizing the top of the frame

[John Yates]

(Reviving a 5.5 year old thread.)

I coped with a bump from my original 30" monitor to
32".  But recently, when my employer foisted a 42"
behemoth upon me, I had to do something.

The result is mbmb, a Mini-Buffer overlaid on Menu-
Bar proof of concept:

    https://github.com/jsyjr/mbmb

(By day I am a C++ programmer.  This is my first real
attempt at an emacs package of any significance.  Any
and all feedback is gratefully welcome.)

My point is to demonstrate that a mini-buffer that,
when it grows, does not alter the window layout, but
instead occludes a part of the frame, is an entirely
liveable user experience.  I might even argue a less
jarring experience as less of the screen changes.

In its current state, the package is clearly a proof
of concept with a number of rough edges:

* Management of the z-axis is not great; frame
  restacking triggers an error on my Ubuntu box
* Resizing the main frame works well enough
* Moving the main frame does not work at all
  (it appears that the move-frame-functions, at
  least in recent 29.0.50 builds, never get called)
* Occasionally the echo area enters a rapidly
  flashing state; sufficient ^g tend to clear it

That said, even in this state, mbmb represents a
very big improvement in my life on a big screen.
It is now my standard configuration.

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

My next step, when time permits, is to follow-up
on Martin's suggestions about how to move the
mode-line to the top of the window.

Re: Emphasizing the top of the frame

[martin rudalics]

BTW, your minibuffer
frames grows downw
 > My point is to demonstrate that a mini-buffer that,
 > when it grows, does not alter the window layout, but
 > instead occludes a part of the frame, is an entirely
 > liveable user experience.  I might even argue a less
 > jarring experience as less of the screen changes.

I'm using a minibuffer child frame based on that principle for several
years now and it rarely has let me down so far.

 > In its current state, the package is clearly a proof
 > of concept with a number of rough edges:
 >
 > * Management of the z-axis is not great; frame
 >    restacking triggers an error on my Ubuntu box

Which error?

 > * Resizing the main frame works well enough
 > * Moving the main frame does not work at all
 >    (it appears that the move-frame-functions, at
 >    least in recent 29.0.50 builds, never get called)

Here I get the expected messages when I evaluate

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

 > * Occasionally the echo area enters a rapidly
 >    flashing state; sufficient ^g tend to clear it

I have never seen such behavior here.  If you do not directly interact
with the minibuffer in such a situation, it might depend on some minor
mode like eldoc-mode enabled (I don't show eldoc in the echo area).

 > That said, even in this state, mbmb represents a
 > very big improvement in my life on a big screen.
 > It is now my standard configuration.

You waste cycles updating the menubar, though.  Have you ever tried
putting the minibuffer frame on top of the title bar?

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

martin

Re: Emphasizing the top of the frame

[John Yates]

Hi Martin,

Hi Martin,

I failed to make this obvious in my previous post, but
I have two agendas:
* Make my own life tolerable on my 42" screen at work
* Provide a sufficiently complete mockup of a top-focused
  emacs that I can trigger some interest in making such a
  mode part of the core

I envision three components to such a mockup:
* Demonstrate that a minibuffer at the top need not imply
  all of the rework that would be necessary to support
  frame relayout on minibuffer expansion
* Demonstrate mode-lines at the top of windows
* Convince maintainers of some key minibuffer interaction
  packages to support downward growth (more below)

> BTW, your minibuffer
> frames grows downw

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.

> I'm using a minibuffer child frame based on that principle for several
> years now and it rarely has let me down so far.

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.

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.

>  > * Management of the z-axis is not great; frame
>  >    restacking triggers an error on my Ubuntu box
>
> Which error?

I solved this one...

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.  (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 \
  --prefix=/usr/local/emacs \
  --program-transform-name='s/^ctags$/ctags.emacs/' \
  --disable-year2038 \
  --disable-acl \
  --with-modules \
  --with-json \
  --with-file-notification \
  --with-native-compilation \
  --with-xwidgets \
  --with-pgtk \
  >/tmp/config

>  > * Occasionally the echo area enters a rapidly
>  >    flashing state; sufficient ^g tend to clear it
>
> I have never seen such behavior here.  If you do not directly interact
> with the minibuffer in such a situation, it might depend on some minor
> mode like eldoc-mode enabled (I don't show eldoc in the echo area).

Ah. Yes. eldoc-mode.  Will disable that.

> You waste cycles updating the menubar, though.

At home and at work I have a hunky desktop.  I do
not observe any impact from menubar updates.

>  Have you ever tried
> putting the minibuffer frame on top of the title bar?

Yes I have.  The subjective experience was less
pleasant as my emacs frame(s) diverged visibly
from the ui conventions.

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.

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

/john

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

Re: Emphasizing the top of the frame

[John Yates]

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

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

RE: [External] : Re: Emphasizing the top of the frame

[Drew Adams]

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

FWIW, I prefer what Epoch did back in the 90s,
which is to have a monitor-wide separate
minibuffer frame.  I use that approach, and I'm
able to resize other frames (automatically or
on demand) to not overlap that piece of monitor
real estate.  I can always clearly see the
single  minibuffer/echo area, and it's always
in the same place.  

Frames can overlap, in general, and that can be
advantageous.  It can also be useful to prevent
or avoid overlapping, and that's what I do for
my standalone minibuffer (and echo area) frame.

I put that frame at the bottom of the monitor
(automatically, based on monitor size etc.).
But it can also be placed at the top.  And it
can be allowed to move, etc. to be positioned
near the cursor (in which case it overlaps
another frame or more).

It can also automatically (or on demand) grow
& shrink in height - or not.  That's important
for me because it's not too unusual for me to
have multiline minibuffer input.

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

Emacs generally has limited support for using
frames, compared to windows.  Partly because
frames are ultimately under the control of a
window manager.  And partly (IMO) because of a
relative lack of experience/interest/attention
wrt frames on the part of Emacs developers and
most users.

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

Yes, and changes in Emacs development can make
this worse across releases.  Getting things to
work properly is then frustrated by breakage
in a future release.

And this is exacerbated by the problem cited
above: new features, bug fixes, and other
changes can get implemented with little/no
attention to the effects on focus for frames.

And debugging the effects of such changes is
not easy.  And if changes are made in C code
then things become even harder.
___

All of what I've written here is just "FWIW",
i.e., for info.  It's general, abstract.  I
don't expect that it helps operationally, wrt
making things better.  Maybe it will somehow
help in the long run, if some more attention
is drawn to using frames, towards becoming
more on a par with using windows.