Re: Window configurations

[Stefan Monnier]

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

Makes sense, yes/

> Maybe we also agree that we should show such a buffer when the window
> was "stolen" by a construct like `with-temp-buffer'.

with-temp-buffer is probably a poor example since it doesn't affect
windows, but if you mean something like with-output-to-temp-buffer, then
yes, we probably all agree.

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

We can solve each case as it shows up.  E.g. for the split-window case
(i.e. buffer shown in 2 windows only because that's what split-window
does, but the user then immediately switches to some other buffer), we
should try and find a way to capture the user's intention.
E.g. "immediately" after split-window, any set-window-buffer will not
push the current buffer on the buffer-list of that window.

>> And maybe you're right that in "all" cases, trying to restore the
>> previous window state is TRT, rather than choosing some
>> non-shown buffer.
> I cannot be right since I never proposed that ;-)

I thought you suggested to have a config var to decide whether to use
the current heuristic, or to use another heuristic which prefers buffers
from the window's buffer-list regardless of whether they are
shown elsewhere.  Isn't that what you meant in:

   >> we should think about how we can tell which is
   >> the better choice in a given situation.
   > We could make this customizable.


-- Stefan