Re: Window configurations

[Stefan Monnier]

> (1) All calls to `other-buffer' for determining which buffer to show in
> a window have the second argument nil.  So if a buffer is already shown
> in another window it's against some unwritten rule to show it in the
> window in question again.  If I follow that rule, then working with two
> windows showing the same buffer remains just as tedious as it is now.

Yes, the window handling code currently considers that the most likely
thing the user wants is to see a buffer that's not currently shown.
[ I'm not sure if it's careful to distinguish "shown on the current
terminal" from "shown in some other terminal, miles away from here",
which it should. ]
This seems like a good default rule, so if we/you want to not follow
this rule in some cases, we should think about how we can tell which is
the better choice in a given situation.

> (2) The length of frame-local buffer-lists is unbound.  For a one-frame
> user this already doubles the consing and maintenance overhead of buffer
> lists without any gain.  If we add window-local buffer-lists, we'd
> double the current overhead once more for one window/one frame users.

Is this overhead really significant?  Say the list is 100 buffers long,
that's 1 or 2 KB, right?  Isn't this lost in the noise?

> (3) For each buffer on the window-local buffer-list I'd have to maintain
> its old point and its old window start position as markers.  Otherwise
> restoring the buffer would either get me a silly position if the buffer
> was modified in the meantime (a rare case probably, but unacceptable
> nevertheless) or a useless position like `point' (which would usually
> coincide with `window-point' of some other window showing that buffer).
> This means that for each buffer we get as many additional markers as
> there are live windows in which the buffer was shown (times two).

The use of `point' for that has not brought many complaints over the
many years it's been used.  Any reason to think it's a bad choice?


        Stefan "who coded up a hack for doc-view which preserves
                window-specific buffer-positions"