Re: idea -> internal frames?

[Richard Stallman]

    > For speedbar, should the window be outside the usual window hierarchy?
    > In other words, should next-window and walk-windows see the speedbar
    > window, or should they ignore it?

    IMHO, these commands should ignore Speedbar.

Some other questions, to figure out what is the most useful feature
for this job:

* Should there be any keyboard-command to select the Speedbar window?

* Should it be possible for a Lisp program to select the Speedbar
window, even temporarily?

* Are there internal uses of walk-windows (or equivalent constructs)
which do need to see these windows, perhaps for redisplay purposes?
In particular, I am thinking of the code that checks whether a buffer
appears in more than one window, but there could be others.

* Should the speedbar window have the full height of the frame,
including the minibuffer's share of the height?

Anyway, it seems to me that the best feature for this sort of thing is
to be able to create some special windows at any edge of a frame.
These windows could be designed so that they never change size except
when the frame does, and are not deleted by one-window.

next-window would normally not see them, but there could be a special
mode in which it does see them.  Or each of these windows could have a
flag which controls whether next-window will see it.

An internal design question: should these windows be part of the usual
window-tree data structure, or stored in some separate data structure?
Each alternative makes some jobs easy and makes some jobs hard.

Maybe the frame's root_window field would point to the uppermost
"ordinary" window, and we would have a new field outer_root_window to
point to the uppormost window including special windows.  This way,
special windows could be split off either horizontally or vertically,
and when both are done they could be done in either order.