emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: martin rudalics
Subject: Re: [ELPA] Brief v5.90: neighboring window merge on deletion
Date: Tue, 26 Mar 2024 10:57:23 +0100
User-agent: Mozilla Thunderbird

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]