[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
- [ELPA] Brief v5.90: neighboring window merge on deletion, 路客, 2024/03/22
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, Emanuel Berg, 2024/03/22
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, Juri Linkov, 2024/03/23
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, 路客, 2024/03/24
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, martin rudalics, 2024/03/24
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, 路客, 2024/03/24
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, martin rudalics, 2024/03/25
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, 路客, 2024/03/25
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion,
martin rudalics <=
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, Eli Zaretskii, 2024/03/26
- Re: [ELPA] Brief v5.90: neighboring window merge on deletion, martin rudalics, 2024/03/27