Re: Window configurations

[Juri Linkov <juri@jurta.org>]

>>> ... where `quit-restore-window' here replaces `quit-window' which has
>>> too obscure semantics for my taste.  And obviously, exiting `view-mode'
>>> calls `quit-restore-window' here too.
>>
>> Yes, `quit-window' is useless because it doesn't help to avoid the mess
>> that occurs after killing buffers.
>
> You don't mean buffers killed by `quit-window' but by some standalone
> `kill-buffer' I suppose?

I mean `quit-window' with non-nil argument KILL.  When its argument KILL
is nil (when the buffer is buried), the problem is the same.

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

> It doesn't solve any of these problems yet because `dired-find-file'
> uses `switch-to-buffer' and in `switch-to-buffer' I don't record any
> information about the dired buffer.  I obviously could do so easily but
> we'd have to find a general agreement first.
>
> And, for lack of a history, it works only for the last `display-buffer'
> action which is sufficient for view mode purposes (by reverting to the
> last buffer displayed before view mode was entered).

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.

>> 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 every kill-buffer could remove it from the
>> history stack (and call its function at the same time).
>
> `kill-buffer' would probably scan all live windows' history stacks.

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.

> But are we sure that a stack (a deque, rather) is sufficient?

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.

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