pillule writes: > martin rudalics 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. Sorry I forgot a last fix on `quit-restore-window' in the last message please consider instead this one : (because switch-to-prev/next-buffer must return nil in case of no available buffer, we can use it in conditional and simplify the code, also the previous version was changing the behavior of some windows by deleting them when it was not necessary)