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

[martin rudalics <rudalics@gmx.at>]

 > If we had a function that can look into window states, then a user
 > could put it on kill-buffer-hook to look into window states stored
 > in user variables.  It would be useful to have a function to check if
 > a buffer exists in window state: often there is a need not to kill
 > a buffer if it's stored in some window state variable (so restoring
 > a saved window state will always show the same buffers as before).

The same argument would hold for window configurations.  And looking
into those is even more difficult.

 >> But we don't yet have a
 >> sufficiently reliable mechanism for providing a serializable value for
 >> a number of our objects - in particular windows and frames.
 >
 > A serializable value of window objects are window states.  By analogy with
 > the eq/equal dichotomy, window objects can be compared with ‘eq’, and
 > window states with ‘equal’.

I meant that window objects cannot be reliably reconstructed from
states.  The more obvious reason is that a writable state can record a
buffer only via its name and buffer names will be assigned in the way
files shown by buffers are visited.  Less obvious reasons are that the
'dedicated' value or the values of window parameters may be arbitrary,
non-serializable Lisp objects you cannot reconstruct either.  So we
have no reliable bijective mappings from states to configurations and
comparing two states for equality may produce arbitrary results.

States are useful for reconstructing a configuration that existed
earlier in some approximate way as to be used by desktop and friends.
Nothing more.

martin