Re: Window tree and window's internal height

[martin rudalics <rudalics@gmx.at>]

 > I thought of saying something like
 >
 >    The minibuffer window does not have a parent window, but it
 >    nevertheless is a sibling of the frame's root window, and thus can
 >    be reached via window-next-sibling.

I'd start the sentence with "A minibuffer window that is not alone on
its frame ..." but for the rest it's fine with me.

 >> I miss you here.  The display code is the major client of this trick
 >
 > And you therefore assumed that I must remember this factoid by heart?

Indeed, I did.  Also because most of the Elisp windows code I added
swirls away this factoid by using 'window-right' and 'window-left'.

 > I don't.  I've read the description of the window tree, and thought
 > "this is a single window on its TTY frame, it cannot possibly have
 > anything non-nil pointed to by its 'next' pointer".  Oops!

So sometimes such details are important in the manual.  Still, I
wouldn't rely on the Elisp manual to tell me anything about the
underlying C structures.

Inherently, the root of each window tree is a virtual "inner frame"
window which must have at least one and at most two child windows -
the root window and the minibuffer window.  This is important for
resizing operations which have to guarantee that the heights of the
minibuffer and root window sum up to the height of the inner frame.

Since for the rest that virtual window has no importance - once set
up its child windows can never change - code for it was never written
out explicitly.  So a correct specification of our window tree concept
would have to talk about that inner frame window but then the entire
definitions of root window would have to be rewritten ...

 > I guess you will need to invent one more "bastard" node in the tree
 > that doesn't have a parent?

And make it the next sibling of the other minibuffer window.  It gives
up the idea of an "ordered" tree but since the root has a next sibling
already it's not a rooted tree anyway.

 > No.  The code is very unequivocal:
 >
 >    /* If we must, use the pixel-based version which is much slower than
 >       the line-based one but can handle varying line heights.  */
 >    if (FRAME_WINDOW_P (XFRAME (XWINDOW (window)->frame)))  <<<<<<<<<<
 >      window_scroll_pixel_based (window, n, whole, noerror);
 >    else
 >      window_scroll_line_based (window, n, whole, noerror);

The code is unequivocal, the comment leaves much room to
interpretation.

martin