Re: Window configurations

[martin rudalics]

>> The culprit here is the `other-buffer' call when unshowing the buffer.
>> Practically all occurrences of `other-buffer' in window handling code
>> are harmful.  Their original purpose was to make sure that the same
>> buffer isn't displayed twice on a frame I suppose.
>
> Yes, and occurrences of `(car (buffer-list))' are harmful too.

Obviously.  It just makes it more difficult grepping them.

> It is sufficient because it stores this information in the buffer-local
> variable `view-return-to-alist'.  I don't think a similar variable
> would help for other non-view buffers because it is specific to windows,
> not to buffers.  So it seems a window parameter is more suitable.

What I meant is this: With view-mode the variable is useful in the sense
that when I exit view-mode I get the last non-view-mode buffer shown in
that window.  For commands like "show me the last meaningful view-mode
buffer when I'm already in view mode" or "show me the last meaningful
non-view-mode buffer when I'm not in view-mode" I need a stack where to
pop that buffer from.

>>> Then every switch-to-buffer could add a `quit-restore' element to the
>>> window history parameter,
>> We'd have to enumerate all actions that would add such an element.
>
> I think it should be every action that changes the window's buffer.

And these should all boil down to `set-window-buffer' calls.

> No need to scan all windows' history stacks.  During restoring the saved
> state from the stack, we could drop elements with killed buffers and
> continue popping the stack until we find an element with a live buffer.

OK.  If we put an upper limit on the size of such stacks, stale entries
will get removed automatically after some time.

> I think this window parameter should be treated like the frame parameter
> `buffer-list'.  E.g. `other-buffer' prefers selected frame's buffer list
> instead of the global buffer list, etc.

We'd have to specify the meaning of "prefers" here.

martin