[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Window tree and window's internal height
From: |
Eli Zaretskii |
Subject: |
Re: Window tree and window's internal height |
Date: |
Sun, 18 Nov 2018 22:25:00 +0200 |
> Date: Sun, 18 Nov 2018 20:40:43 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden
>
> >> > 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.
- Window tree and window's internal height, Eli Zaretskii, 2018/11/17
- Re: Window tree and window's internal height, martin rudalics, 2018/11/17
- Re: Window tree and window's internal height, Eli Zaretskii, 2018/11/18
- Re: Window tree and window's internal height, martin rudalics, 2018/11/18
- Re: Window tree and window's internal height,
Eli Zaretskii <=
- Re: Window tree and window's internal height, martin rudalics, 2018/11/19
- Re: Window tree and window's internal height, Eli Zaretskii, 2018/11/19
- Re: Window tree and window's internal height, martin rudalics, 2018/11/20
- Re: Window tree and window's internal height, Eli Zaretskii, 2018/11/20
- Re: Window tree and window's internal height, Eli Zaretskii, 2018/11/20
- Re: Window tree and window's internal height, Richard Stallman, 2018/11/20