Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Wed, 26 Oct 2016 14:31:18 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  >> 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.