martin rudalics <rudalics@gmx.at> writes:

> 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.

Yes.

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

I can test the changes against a version of DOOM, yes. For the draft below
it seems to be ok, but keep in mind that their library bypass these parts
window.el

> If you feel that it's more natural to delete the window in the case at
> hand, we can consider that too.

Not at all. For me it is ok with switch-to-prev-buffer, if users want to delete
the window and/or buffer explicitly, they have commands for that. In the case of
DOOM it is implemented as a workaround against some bugs, it is
explicated in :

(+popup/quit-window)
Documentation
The regular quit-window sometimes kills the popup buffer and switches to a
buffer that shouldn't be in a popup. We prevent that by remapping quit-window
to this commmand.


So here is the *draft* that pass the previous cases of this thread.
`replace-buffer-in-windows' take care of killing buffers.
I restore the dedication of side-window because :
1. it seems to me it is the right think to do, and it prevents 2.
2. I lost the trace when we kill a buffer and no previous-buffer is found
but  still an undesirable buffer replace the current,
is it in the C part ? I can't inspect C...