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

[martin rudalics <rudalics@gmx.at>]

 > 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