Re: Window configurations

[martin rudalics <rudalics@gmx.at>]

 > Maybe a matter of taste but I would not count on more conclusive behavior
 > from even more new options that allow packages to do what you want in case
 > anyone bothers to understand the complex specifications.  Instead it might
 > be much more effective to implement conclusive behavior in a simple
 > algorithm
 > and remove any options for packages to circumvent it.

I didn't describe a new option.  The parameter I described is implicitly
present in the current behavior of help windows.  What I did was moving
it from such windows to `display-buffer' and also to a function intended
to get rid of window contents in some way.

 > For instance, one could have a buffer stack for each window, such that each
 > buffer displayed is added on top of the window's buffer stack.

Probably a buffer should be added at the time it's unshown and still
alive - yet another complication for `kill-buffer'.

 > If a
 > buffer is
 > killed or hidden, then the window's next buffer is displayed.

That's more or less what I do now - modulo the stack behavior, but this
could be changed.  One complication is that window configurations would
have to store the buffer stack and all buffer references.

What's more problematic, however, is that it's not clear whether each
and every occurrence of `set-window-buffer' should add its buffer to the
stack.  Currently, I put a buffer there only when `display-buffer'
displays it.  And, obviously, stacks have the usual annoying attitude to
forget about their tops, so sooner or later someone will come up and ask
for a ring or eventually a buffer history tree for each window and some
way to navigate it.

 > If there is
 > no "next", then the window is deleted (including the frame if it's the last
 > window).

I agree.  That is, I would certainly delete such a window if it never
displayed another buffer since it was created.  Also I would never
iconify a frame.  I'm not 100% sure whether a window should be deleted
because all buffers it displayed have been killed in the meantime.

But all this doesn't easily solve the problem of displaying a buffer in
the intuitively right window, for example, the window where it has been
already shown a couple of times before.  For this we could scan all
windows' stacks and pick the one that has this buffer at the most
prominent position - maybe supplied with some sort of a time-stamp.

martin