Re: Window configurations

[martin rudalics]

> If we don't know the target window in advance, then we can't use
> the window-local buffer-list for `read-buffer-to-switch'.

In `switch-to-buffer' we usually know the target window.  In
`switch-to-buffer-other-window' we don't.  How distinguish the two?

But I'm afraid that the idea of handling window local buffer lists just
like the other buffer lists is flawed anyway.  For example, when I
display a buffer without selecting the window as in
`with-output-to-temp-buffer' I do want to update the window local buffer
list.  When I do `bury-buffer' and the buffer is not displayed in the
selected but maybe some other window the buffer will get buried in the
selected window and remains the first buffer in the other window.  Both
make hardly sense either (and are flawed for frame local buffer lists as
well).

I suppose that for the moment I'll abandon the idea of window local
buffer lists and return to them after I have solved some other issues.

> This means that you need to store more information for the first
> element of the window-local buffer-list, i.e. when popping the
> stack of buffers reaches the first element, it should know what to do
> after popping the last element: whether to kill the window and
> which window to select instead.

The problem is that the information contained there might be already
stale (the user might have done a lot of things in between).  For help
windows it makes sense to check whether the window still displays the
help buffer and only if it does I proceed according to the information
stored in the window parameter.  For arbitrary buffers in non-dedicated
windows I might just violate the principle of least surprise.

martin