Re: Window configurations

[Juri Linkov]

>> So you're saying that C-x k's heuristic should be to try and restore
>> the previous window state?  I guess that could make sense, yes.
>
> I was saying that _if_ we want to fix the behavior to handle Juri's
> case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or
> something the like).

I think changing the argument VISIBLE_OK won't help.  The existing
calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
current behavior of `other-buffer' that prefers not visible buffers
to visible buffers (when the window-local buffer-list is empty).

>>> We could make this customizable.
>>
>> No, we want instead to try and think in each case which behavior would
>> make more sense.
>
> We probably all agree that a window should not show a buffer visible
> elsewhere when its buffer is killed or buried and its window-local
> buffer list contains no other buffer.

Yes, without making this customizable, a simple rule could be to get
next buffers from the window-local buffer-list when it is non-empty.

> However, I'm afraid that there's no good approximation for the remaining
> cases.  There are people used to edit large buffers by showing related
> sections in two or more windows.  And there are people who don't do
> that.  [The latter group should not be affected much by the new behavior
> since we expect them to never show the same buffer twice at the same
> time.  But I'm not sure whether the use of `split-window' runs counter
> to such an assumption.]

I see no problem if we will push the current buffer to the window-local
buffer-list in the same places in code where currently the buffer is
pushed to the frame-local buffer-list (and buried-buffer-list).

-- 
Juri Linkov
http://www.jurta.org/emacs/