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

[martin rudalics]

>> 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