Re: Window tree and window's internal height

[martin rudalics]

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

> 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 I suppose it has been invented only to make all these "while (w)"
constructs in dispnew.c seamlessly work on the minibuffer window too.
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 don't think we should assume that the ELisp
> manual is only for people who work on the Lisp level.

Section E.9.2 Window Internals is not very enlightening either in this
regard (and it hasn't seen an update for decades).

> Well, I guess that answers my question: it's simply a very old bug.

A window that has no parent, no next and no prev is alone on its frame
- either a minibuffer-less frame or a minibuffer only frame.  So the
tests allow to conclude that the window is not alone on its frame.
But this shouldn't imply that the window has a modeline.  Maybe in the
old days it did.

>> I would call window_body_height on the release branch and on master.
>
> window_body_height attempts to calculate the mode-line and header-line
> heights in pixels, which might be expensive and if so entirely a waste
> of CPU cycles on TTY frames.

Right.

> But I guess this indirectly answers my
> question, because my proposed change in window_internal_height will
> make it the exact equivalent of window_body_height for TTY frames.  So
> I think I will make that change on the release branch.
>
>> 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.
>
> 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.

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

Right.

martin