Re: Window tree and window's internal height

[martin rudalics <rudalics@gmx.at>]

 > First, we have this in the ELisp manual:
 >
 >       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.
 >
 > The first sentence is incorrect, isn't it?  Because Emacs disagrees:
 >
 >    emacs -Q
 >    M-: (window-next-sibling) RET
 >     => #<window 4 on  *Minibuf-0*>
 >
 > And if that sentence is incorrect, we don't need the next two
 > "exceptions", right?

Right, graph theoretically.  For a long time, however, the Elisp manual
has used the term "root", for example, in Emacs 22 as follows

      The return value is a list of the form `(ROOT MINI)', where ROOT
      represents the window tree of the frame's root window, and MINI is
      the frame's minibuffer window.

which implies that Emacs' window tree is not free but a "rooted tree"
and in a rooted tree every node except the root must have a unique
parent node.  But the minibuffer window does not have a parent so we
would have two nodes without parent.

Which means that our window tree concept per se is valid but using
'window-next-sibling' to get the minibuffer window from the root
window is an incorrect naming convention.  It's simply there because
'window-next-sibling' is a 1-to-1 reflection of the w->next field of
the window structure in window.h.

 > Next, please have a look at the function window_internal_height:
 >
 >    /* Return number of lines of text (not counting mode lines) in W.  */
 >
 >    int
 >    window_internal_height (struct window *w)
 >    {
 >      int ht = w->total_lines;
 >
 >      if (!MINI_WINDOW_P (w))
 >        {
 > 	if (!NILP (w->parent)
 > 	    || WINDOWP (w->contents)
 > 	    || !NILP (w->next)
 > 	    || !NILP (w->prev)
 > 	    || window_wants_mode_line (w))
 > 	  --ht;
 >
 > 	if (window_wants_header_line (w))
 > 	  --ht;
 >        }
 >
 >      return ht;
 >    }
 >
 > I don't understand any of the conditions except window_wants_mode_line
 > when we decide whether to decrease the height due to the mode line.
 > What do the other conditions have to do with the window's height?  I
 > could perhaps understand the "WINDOWP (w->contents)" part, as some
 > kind of optimization for non-leaf windows, which assumes the default
 > of having the mode line, but the rest seem simply wrong, don't they?
 > (The WINDOWP condition is not really interesting, as I don't see any
 > call of this function for a non-leaf window.)

Whatever these three conditions were meant for is beyond my
imagination.  window_internal_height was always off-limit for me.  I
wonder how these miscalculations would affect window_scroll_line_based
(I hardly ever use modeline-less windows) though.

 > This is the immediate cause of bug#33363, which I could fix either by
 > a local change in try_window_id, or by modifying
 > window_internal_height to leave only the window_wants_mode_line
 > condition there.  If the latter might be unsafe, maybe I should do the
 > former on the release branch and the latter on master.  WDYT?

I would call window_body_height on the release branch and on master.
And I would use window_body_height in window_scroll_line_based too.
It should then take care of dividers and horizontal scroll bars on GUI
windows as well.

martin