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

[martin rudalics <rudalics@gmx.at>]

 > Which is what I think you are asking and IMHO ask to deal with the
 > dedicated window state to not cripple side-windows.

You're right, I forgot that side windows are by default dedicated to
their buffers.

The dedicated flag in a side window serves to prevent "normal" buffer
display to "avoid" that window.  A side window may be reused for showing
another buffer only by `display-buffer-in-side-window'.  This sense of
dedication is somewhat different from the normal sense where killing the
buffer always attempts to delete its dedicated windows (and maybe their
frames too) first.

Hence it is perfectly valid to switch to the previous buffer here - any
such buffer was meant to be displayed in that side window.  It would be,
however, invalid to switch to some buffer that was never shown in that
window here.  Note in this context that we can always delete a side
window, a side window can never be alone on its frame.

 > Thanks for the snippet, I think I am confused by this window dedication,
 > please help me to clarify my mind before I try to implement a solution
 > with or without the dedicated window state.

So maybe something like this might cut it:

       (if (and prev-buffer (memq (window-dedicated-p window) '(nil side)))
           ;; If a previous buffer exists, try to switch to it.  If that
           ;; fails for whatever reason, try to delete the window.
           (unless (switch-to-prev-buffer window bury-or-kill)
             (window--delete window nil (eq bury-or-kill 'kill)))
         ;; If no previous buffer exists, try to delete the window.  If
         ;; that fails for whatever reason, try to switch to some other
         ;; buffer.
         (unless (window--delete window nil (eq bury-or-kill 'kill))
           (switch-to-prev-buffer window bury-or-kill)))

Tell me whether this works with DOOM's `kill-buffer-hook'.

If you feel that it's more natural to delete the window in the case at
hand, we can consider that too.  But suppose someone uses such a side
window for something more permanent like a compile or shell buffer and
the backtrace buffer kicked in only accidentally, then deleting the side
window when killing the backtrace buffer might not be a good idea.

martin