Re: MY window tree!

[martin rudalics <rudalics@gmx.at>]

 >>  > 1) I think I must search all buffers
 >>
 >> No.  Only the buffers that have an ovlwin-window association.
 >
 >
 >
 > There is unfortunately no way to find out if a buffer have that without
 > looking at the overlays in the buffer AFAICS.

It's all in the loop below where you ask "Why should I only investigate
those buffers?"

 >>  > 5) If that window is not on a frame any more I just replace the value
 >>
 >> Together steps 1) and 4) assert that the window is not on a frame any
 >> more, hence, you don't have to check this.
 >
 >
 >
 > If you are thinking of the normal use case (which is adding a BAR
 > window, see winsav.el) you are right, but there may be other ways to use
 > this too. In those cases the old windows may still be there on the old
 > frame. (The user of these functions may for some reason be copying the
 > window structure somewhere else. Do not ask me why, but the possibility
 > to do that is there.)

Why not?  The primary purpose of the 'window property is to make the
overlay appear in one and only one window.  Copying the window tree
somewhere else should move the overlay to a new window iff the old
window were deleted.  Perfectly valid.  Copying again from the saved
configuration would not see the overlay any more because it now names
another window.  Valid too.

If you really see a need to copy overlays make it optional.  In any case
there's no need to scan the entire `buffer-list' for overlays.  Any
buffer involved must have been displayed by the old window-tree and must
be displayed by the new window-tree.

Finally, if you really want to separate saving from restoring you have
to decide what to do with buffers that have been changed (window-point
or window-start are no longer valid) or deleted in the meantime.

The current problem is that of making non-orthodox window splitting as
transparent as possible.  That is, the user should not notice that you
delete and create any other windows but the very one she wanted to add.
I'd even suggest to write a `split-root-of-window-tree' command that
hides the saving and restoring stuff completely, 'horizontal non-nil
means add the new window on the left, nil at the bottom.  Interactively,
the buffer displayed in the new window would be that of the selected
window which also designates the root of the window-tree.

 >> (dolist (buf (let (buffer buffers)
 >>            (dolist (win win-list buffers)
 >>              ;; I presume cadr refers to the "new" window.
 >>          (setq buffer (window-buffer (cadr win)))
 >>          (unless (memq buffer buffers)
 >>            (setq buffers (cons buffer buffers))))))
 >>   ...
 >
 >
 >
 > Why should I only investigate those buffers?

Because people may have hundred buffers or more, many of them with
overlays.  Most overlays don't have a window property.