martin rudalics <rudalics@gmx.at> writes:
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?
Yes.
Maybe it is a step toward implementing the `soft' dedication
that is mentioned in the comments.
Thanks you for the explanations.
We have to document it in the Elisp manual.
Here another draft with the info manual changes:
From what I have tested so far, there were more functions that
needed to preserve the side
dedication. I put in my modeline a token for the window
dedication and it was quite useful to spot
them (maybe not the clever way but worked). I also grepped into
window.el to see if I was missing
something without more success.
There is a change in the indentation of `quit-restore-window'
and I don't know if there is
convention in such cases.
0002-Improve-handling-of-side-dedicated-flag.patch