Window restoration glitches

wasamasa commented 8 years ago

I suspect these were there ever since I succumbed to using setf to modify conses...

wasamasa commented 8 years ago

As I cannot reproduce this and there is a single setf call in a little used function for renaming tags. I'm closing this for now until it comes biting me again.

wasamasa commented 7 years ago

I've managed to find a repro case for this:

Start with one workspace and no window splits
Split window: C-x 3
Open buffer in it: M-x find-function RET kill-buffer-and-window RET
Duplicate workspace: M-2 (assuming you use opinionated bindings and didn't customize new workspace behavior)
Kill opened buffer and window: C-x 4 0
Switch to previous workspace: M-1 (assuming you use opinionated bindings)

Expected behavior: First workspace still shows two windows.

Actual behavior: First workspace has only one window.

Notes:

Cannot be repro'd with C-x 0, it must be C-x 4 0
Using C-x k does also trigger the bug

wasamasa commented 7 years ago

Tracing the window-state-put function reveals that this is not a bug, but a feature. If a window associated with a dead buffer is found, it's marked for later deletion and eventually deleted.

I'm not sure whether to bother reporting this behavior for further discussion. What I could do is processing the window configuration before saving it, then replace dead buffers, like by using the algorithm behind replace-buffer-in-windows or just always using the scratch buffer.

wasamasa / eyebrowse

Window restoration glitches #55