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

[martin rudalics <rudalics@gmx.at>]

 >> This means that buffer overlays with a 'window' property will not work
 >> correctly in any of the new ones.
 >
 > Overlay is a good point, but can be saved before reconstruction and
 > restored afterwards in the affected windows.  My code try to restore as
 > many window properties as possible but the overlay is surely a missed
 > one.  It will be taken care of in my next release.

The problem is not a new one - it's been present in 'window-state-put'
ever since.  It could be easily mitigated with the help of the
'clone-of' window parameter which would have to be processed here in
xdisp.c's load_overlay_strings

       Lisp_Object window = Foverlay_get (overlay, Qwindow);
       if (WINDOWP (window) && XWINDOW (window) != it->w)
         continue;

but I never got around to do that.

 >> Moreover, if such windows were stored in Lisp variables, they would be
 >> considered dead although they apparently still exist like the ones in
 >> the lower part of your frame.
 >
 > If some code store windows in variables, Emacs native window deletion
 > will also make it dead,

Right - but IIUC your code pretends that such a window is alive, yet
with another identity.  Still, the same problem exists with
configurations produced by 'window-state-put' and the only remedy I see
is to use the 'clone-of' parameter and maybe some special function like
'windows-equal-p' that would handle it.

 > besides, Emacs does not seem to provide a hook
 > for deleting windows

'window-state-change-functions' is called in such case but it does not
provide you with a list of the windows that have been deleted.  The
Elisp manual says:

      Note that window change functions provide no information about which
   windows have been deleted since the last time they were run.  If
   necessary, applications should remember any window showing a specific
   buffer in a local variable of that buffer and update it in a function
   run by the default values of any of the hooks that are run when a window
   buffer change was detected.

We could provide a frame-based 'window-old-window-list' though if you
think it's needed.

 > thus codes that store windows in variables should
 > always consider the possibility if a window is dead.  I know the point
 > is that my window reconstruction makes it appear to be still alive.  As
 > with most other features, it can be configured to default OFF and switch
 > back to native Emacs window deletion behavior when causing problems.
 > But so far I haven't met such a problem yet.  If there is such a case I
 > hope the designers who store windows in variables provide hooks so that
 > I can add support on this.

martin