bug#32850: 27.0.50; window-swap-states doesn't swap window prev/next-buffers

[martin rudalics]

>> Which problems do you see in practice?  I have no idea about the
>> internals of desktop.  If you mean that the windows' states have to be
>> saved too often -
>
> Yes, too often - according to desktop-auto-save-timeout, it should do
> this juggling with window configurations and states every 30 seconds.

That's not reasonable.  More often than not this will catch the
current window configuration in an inconsistent state where the
minibuffer is active or the user is in a window excurstion.

But does desktop save window configurations or states stored somewhere
in the first place?

> In fact this means maintaining a duplicate data structure,
> i.e. in parallel to keep in one list - window configurations,
> but in another list - window states.  The downside is data duplication.
> If this is the only available solution, then it's ok.
>
> But the problem is that window configurations can't be used
> even in the same session, because they don't keep prev/next-buffers.
...
> But unfortunately set-window-configuration doesn't restore
> the old values of prev/next-buffers.

That's disputable anyway.  When, in a window excursion, you show some
buffer in a window, don't you want to record that buffer in that
window's list of previous buffers after exiting from the excursion?

Anyway.  It would be tedious but probably not impossible to provide a
function that transforms a configuration into a state.  Doing the
opposite is conceptually questionable, at the very least.

A basic invariant of the windows code is that a valid window cannot
appear twice on the same or a different frame.  It may, however,
appear an arbitrary number of times in stored window configurations.

One consequence implied by that invariant is that you can restore a
window configuration only into the frame from where you saved it
earlier.  When a frame gets deleted, all configurations drawn earlier
from that frame are virtually lost.

martin