Re: Emphasizing the top of the frame

[Eli Zaretskii]

> Date: Wed, 26 Oct 2016 16:23:39 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  > The TTY display code is frame-based, and for a good reason.  IOW, it
>  > updates the entire frame, not each window separately.
> 
> But for that it (1) has to "walk the window tree as well" and (2) know
> where to draw the minibuffer window.

No, it doesn't.  The window glyph matrices on TTY frames are actually
portions of the frame glyph matrix, so whenever a window's glyphs are
updated by xdisp.c, the corresponding glyphs of the frame are
automagically updated as well.

>  >> Both, a frame's root and minibuffer window, are accessible directly.
>  >> There is no reliance on the prev and next fields of these windows
>  >
>  > There are at least two functions in the display engine that walk the
>  > window tree,
> 
> Which ones are that?

redisplay_windows and hscroll_window_tree.  I now see that so do
mark_window_display_accurate, redisplay_mode_lines,
update_cursor_in_window_tree, and expose_window_tree.

>  > so I'm not sure what you mean by "no reliance on prev and
>  > next").
> 
> I meant the prev and next fields of the root window and the minibuffer
> window.  The next field leading from the root window to the minibuffer
> window is conceptually redundant - but might be still in use somewhere
> as, for example, in ‘window-tree’.

The functions listed above actually use the 'next' pointer when they
walk the window tree.

> The window tree proper is the tree rooted at the root window.  The root
> window and the minibuffer window of a "normal" frame do not form a tree
> - they have no common ancestor.

Maybe I'm missing something, but there's this fragment in make_frame:

  root_window = make_window ();
  rw = XWINDOW (root_window);
  if (mini_p)
    {
      mini_window = make_window ();
      mw = XWINDOW (mini_window);
      wset_next (rw, mini_window);
      wset_prev (mw, root_window);
      mw->mini = 1;
      wset_frame (mw, frame);
      fset_minibuffer_window (f, mini_window);
      store_frame_param (f, Qminibuffer, Qt);
    }

This seems to arrange for the minibuffer window to be the "next" of
the root window, no?

>  > That AFAIU the display engine knows that it can resize the minibuffer
>  > window by moving the lower edge of the root window.
> 
> All the display engine should know is that it can resize the minibuffer
> up to a certain extent.  Deciding who pays for that operation and to
> what extent should be left to the window code.  Think of a one line high
> window bordering the minibuffer window.

I thought you were saying that it knew more than that, but the last
time I looked at that code was long ago.