[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Window configurations

From: martin rudalics
Subject: Re: Window configurations
Date: Thu, 17 Jun 2010 09:58:22 +0200
User-agent: Thunderbird (Windows/20090302)

> 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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]