Re: Window tree and window's internal height

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 18 Nov 2018 20:40:43 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  >>   >       A minibuffer window (*note Minibuffer Windows::) is not part of its
>  >>   >    frame’s window tree unless the frame is a minibuffer-only frame.
>  >>   >    Nonetheless, most of the functions in this section accept the minibuffer
>  >>   >    window as an argument.  Also, the function ‘window-tree’ described at
>  >>   >    the end of this section lists the minibuffer window alongside the actual
>  >>   >    window tree.
> [...]
>  > So maybe we should simply say that the mini-window doesn't have a
>  > parent, instead of what we say now?
> 
> We can do that.  But that would not remove or explain the fact that
> the minibuffer is the next sibling of the root window and the root
> window the previous sibling of the minibuffer window.  We could add a
> sentence like "For convenience, the function `window-next-sibling',
> when invoked with the root window as argument, returns its frame's
> minibuffer window if the frame has a minibuffer window and is not a
> minibuffer-only frame." unless it's even more confusing.

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.

>  > Looking at w->next _was_ what tripped me in the first place: I didn't
>  > expect a sole window on a TTY frame to have a non-nil object pointed
>  > by its 'next' pointer.
> 
> 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?
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!

> I don't like it much because when I want to display a "permanent"
> minibuffer window at the top of the frame, it must be still the "next"
> sibling of the root window.  Worse even - I cannot easily display the
> echo area at the top of the frame and the minibuffer at its bottom in
> two (semi-)permanent windows.

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

>  > window_scroll_line_based is never used on GUI frames,
> 
> I wasn't aware of that.  I always thought the comment
> 
>    /* If we must, use the pixel-based version which is much slower than
>       the line-based one but can handle varying line heights.  */
> 
> means that we would allow for some sort of line based scrolling on GUI
> frames.

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

>  > and dividers and
>  > scroll bars always have exactly zero size on TTY frames.  Right?
> 
> Right.

OK, thanks.  I'll make the changes.