Re: [ELPA] Brief v5.90: neighboring window merge on deletion

[martin rudalics <rudalics@gmx.at>]

 > Is it possible to provide some means so that we can `recycle' or
 > `reuse' the deleted window ID to prevent this kind of problem? In
 > `winner-mode' I saw the window ID is restored even after being deleted.
 > But that seems to be the nice side effect of `set-window-configuration'
 > which is not available for `window-state-put'.  With the latter I can at
 > best make it a `clone-of' the original deleted window.

It would be non-trivial to provide such a mechanism.  There are many
restrictions that allow 'set-window-configuration' to operate
satisfactorily and any new mechanism would have to adopt them somehow.

'undelete-frame', for example, uses 'window-state-put' to restore its
frame's windows, probably because its authors wanted to avoid the
pitfalls of making 'set-window-configuration' work for dead frames.

 > However, as an `emulation' mode, we usually can only expect it to be `as
 > close as possible' to the emulated target application.  After added the
 > `overlay' and full window state save/restoration it's quite close, but
 > of course it's best if I have a way to do it better -- a way to
 > `recycle', `reuse' or even `restore' the deleted window ID like
 > `winner-mode' does.

IIUC handling overlays with a 'window' property with current means is
much too cumbersome.  One would have to investigate all overlays in the
window's buffer and duplicate them if they have a 'window' property that
references the cloned window.  In practice, most overlays don't have
such a property.

 > Actually, even if so, it's still not possible to fully emulate the
 > `merge upon deletion' behavior while 100% keeping original Emacs
 > functionality -- the atomic property of two windows will gone if I force
 > to split them into two different window subtree, which lose the original
 > intention of atomicity so I might again need to add a customization
 > option for users who concern more about merging windows than breaking
 > window atomicity.  It's always a trade-off that users need to decide.

Atomicity is a property of a parent window.  If your operation clones
the parent window, it should retain the property regardless of which its
new child windows are.

martin