Re: Window configurations

[grischka]

martin rudalics wrote:
> ... 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.

You're already lost if you plan to expose details of your design to users
or packages.  If people want rings or history, they can still implement
it on top of your design as a whole.  It is then their responsibility to
make their feature conclusive to yours.

> 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.

One mistake is to cater for windows on the same level of generality as you
obviously do for low level lisp.  Of course you want functions "cons" etc.
to allow generation of arbitrarily complex lisp structures, but it cannot
be the point of "split-window" to generate arbitrarily complex window-trees,
(and anyway the result of some such is not a "window-configuration" but at
most a "window-state").

The other mistake is _not_ to cater for windows on the same level of
_reliability_ as you obviously do for low level lisp.  "Cons" doesn't work
"intuitively" in the sense of "heuristically", and one has to accept that
there is no other "intuitively right window" to display some buffer except
the exactly one defined location where the user wants to see it.

And that is actually what "window-configuration" can only mean:  A way to
define windows for particular content (aka. buffers) _before_ the window
exists physically.

From then on it is easy, you just need to tell "display-buffer" to use that
window rsp. to generate it if it doesn't yet exist.

--- grischka

> martin