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

[martin rudalics <rudalics@gmx.at>]

 > 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

You already told me so.

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

Maybe this is precisely the behavior you're trying to fix and their fix
won't then be needed any more.

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

This is quite a weakness of the present mechanism and I think you got
it right.  To summarize your approach:

- When we have to replace a buffer in a side window, that window's
   dedicated status is 'side', and some other buffer is found that was
   shown there before (it's on the list of that window's _previous_
   buffers) we show that other buffer in the window and make sure to
   restore the window's dedicated status to 'side'.

- Otherwise delete the window.  Deleting the window is always possible
   and we have to make sure one thing - never show in a side window a
   buffer that has not been shown before in that window.  This rule
   should take care of the DOOM workaround.

And users who override the behavior sketched here by setting the side
window's dedicated status to t should have the window deleted (since
that is always possible).

Have I got it right?

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

IIUC you mean the one in `kill-buffer' in buffer.c.  `kill-buffer' first
calls

   replace_buffer_in_windows (buffer);

which simply calls the Lisp function `replace-buffer-in-windows' for
buffer (the buffer to kill) and later on does

   replace_buffer_in_windows_safely (buffer);

That last call will show another buffer in a window if and only if
`replace-buffer-in-windows' failed to do its work which is an unusual
case - one that should _not_ have happened.  But we must, in C, simply
make sure that such a failure gets caught since showing a dead buffer in
a live window can crash Emacs.  So if replace_buffer_in_windows_safely
shows another buffer, then something in `replace-buffer-in-windows' was
already broken before and we need not bother to clean up things.

 > I will pass the rest of they day to look at ERT to see if I can learn
 > how to write reusable tests and see if this discussion needs to be reflected
 > in the documentation.

We have to document it in the Elisp manual.

martin