bug#48493: 28.0.50; quit-window doesn't work

[martin rudalics]

> I think there is still edges cases :
>
> with emacs -Q
>
> ;; set some rules
> (setq display-buffer-alist
>      '(("\\*\\(Backtrace\\)\\*"
>        (display-buffer-in-side-window)
>        (window-height . 0.2)
>        (side . bottom))
>        ("\\*\\(Messages\\)\\*"
>        (display-buffer-in-side-window)
>        (window-height . 0.2)
>        (side . bottom))))
>
> ;; display the *Messages* buffer
> (view-echo-area-messages)
>
> ;; trigger a logical error to display the *Backtrace* buffer
> (> vim emacs)
>
> ;; trigger a quit-restore-window by calling kill-buffer in a   dedicated 
window
> (kill-buffer (get-buffer "*Backtrace*"))
> ;; the dedicated property has been cleaned from the window,
> ;; yet *Messages* is displayed in place of this window !
> (kill-buffer (get-buffer "*Messages*"))
> ;; calling kill-buffer in a non-dedicated window,
> ;; does not trigger quit-restore-window anymore
> ;; resulting in an undesirable buffer being displayed in place.
>
>
> What is the desired behavior of a dedicated window here ?
> Must *Messages* be displayed after we killed *Backtrace* in the first
> place ?

I think so, yes.

> I am suspecting that the locale value of `kill-buffer-hook' in
> *Backtrace* is interfering with this test but I have difficulties to
> find its human readable form.

I doubt that.  It's probably due to my fix for Bug#48493.  When
*Messages* is killed, the window should have no more previous buffers to
display and we should be able to kill it.  But `switch-to-prev-buffer'
shows the "next" buffer instead.  Try to come up with a solution that
does not reintroduce Bug#48493 and deletes the window when no previous
buffer is found.

martin