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

[路客]

On Mon, Mar 25, 2024 at 5:40 PM martin rudalics <rudalics@gmx.at> wrote:
> We could provide a frame-based 'window-old-window-list' though if you
> think it's needed.

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.

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.

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.

Luke