|
From: | pillule |
Subject: | bug#48493: 28.0.50; quit-window doesn't work |
Date: | Tue, 08 Jun 2021 01:23:11 +0200 |
martin rudalics <rudalics@gmx.at> writes:
This is quite a weakness of the present mechanism and I think you gotit 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 torestore 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 ruleshould 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 (sincethat 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 thatneeded 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.
0001-Improve-handling-of-dedicated-side-flag-when-quittin.patch
Description: Improve handling of side dedicated flag
--
[Prev in Thread] | Current Thread | [Next in Thread] |