Re: Window configurations

[martin rudalics]

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

It's not that careful.

> This seems like a good default rule, so if we/you want to not follow
> this rule in some cases,

The case at hand was a scenario earlier posted by Juri as ...

------------------------------------------------------------------------
2. Another example - visit the same buffer in two windows, and put point
at different positions of the same buffer.

+---------+---------+
|         |         |
| dired 1 | dired 1 |
|         |         |
|         |         |
+---------+---------+

Now view a file in the first window, and quit: `v q'.
The window configuration is correctly restored
(without using `set-window-configuration') - good.

Now do the same without `view-mode': `RET C-x k'.
Instead of the original buffer, some random buffer is displayed
in this window.
------------------------------------------------------------------------

... which, together with another scenario, triggered the present
discussion.

> we should think about how we can tell which is
> the better choice in a given situation.

We could make this customizable.

>> (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?

Look at the following stretch from `other-buffer':

  tail = Vbuffer_alist;
  pred = frame_buffer_predicate (frame);

  /* Consider buffers that have been seen in the selected frame
     before other buffers.  */

  tem = frame_buffer_list (frame);
  add_ons = Qnil;
  while (CONSP (tem))
    {
      if (BUFFERP (XCAR (tem)))
        add_ons = Fcons (Fcons (Qnil, XCAR (tem)), add_ons);
      tem = XCDR (tem);
    }
  tail = nconc2 (Fnreverse (add_ons), tail);

This prepends a list of (nil . buffer) conses for every non-buried
buffer on the selected frame (or some specified frame) to the list of
all buffers.  Note that reusing a window in `display-buffer' doesn't
bury the previous buffer.

Now for one-frame Emacs users this means that its consing overhead is
usually always proportional to the number of live buffers.  Given the
fact that `bury-buffer' (and thus `next-buffer') and evaluating the `b'
and `B' interactive arguments all call `other-buffer' this makes me
think that some GC overhead result.

It shouldn't be too hard to fix this.  [`other-buffer' has not been coded
very cleanly, just try evaluating

(other-buffer nil nil 1)

in a _separate_ instance of Emacs.]

Similar problems exist for `buffer-list' and `last-buffer'.

>> (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?

It's a bad choice if you show a buffer in two windows W1 and W2,
temporaily show another buffer in W2, select W1, and switch back to the
original buffer in W2.  The whole "point" of showing the same buffer in
two windows is lost.  Note that if the temporarily displayed buffer is
in view or help mode you don't have this problem since `view-mode-exit'
handles the case.

martin