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

[martin rudalics]

> Now I found a reproducible test case:
>
> 1. create and remember a window-configuration
>
> 2. switch to a different window-configuration
>
> 3. kill the buffer that was in prev-buffers of the
>     first window-configuration
>
> 4. restore the first window-configuration
>
> 5. look into its prev-buffers, it contains:
>
>     (#<killed buffer> #<marker in no buffer> #<marker in no buffer>)

Hmmm... so even live windows can make troubles as soon as they are
stored in a configuration.  You have probably seen the tribulations of
'switch-to-prev-buffer' and 'switch-to-next-buffer' when they
encounter a killed buffer in one of these lists.

> 6. (window-state-get nil t) on the window with such prev-buffers
>      produces:
>
>      (nil nil nil)
>
> I believe this patch should fix the problem:
>
> diff --git a/lisp/window.el b/lisp/window.el
> index 27d7e42280..ad8164052f 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -5552,9 +5552,14 @@ window--state-get-1
>     (buffer (window-buffer window))
>     (selected (eq window (selected-window)))
>     (next-buffers (when (window-live-p window)
> -                   (window-next-buffers window)))
> +                   (delq nil (mapcar (lambda (buffer)
> +                                             (and (buffer-live-p buffer) 
buffer))
> +                                           (window-next-buffers window)))))
>     (prev-buffers (when (window-live-p window)
> -                   (window-prev-buffers window)))
> +                   (delq nil (mapcar (lambda (entry)
> +                                             (and (buffer-live-p (nth 0 
entry))
> +                                                  entry))
> +                                           (window-prev-buffers window)))))
>     (head
>      `(,type
>               ,@(unless (window-next-sibling window) `((last . t)))

OK.  Wouldn't 'window-state-put' run into a similar problem when a
buffer in some prev or next list gets killed in between getting and
putting?

martin