MY window tree!

MY window tree!

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 968 bytes --]

Hi!

I've been playing around with window-tree to do the following :
- On M-x foo, a window is created on the extreme left of the frame,
containing a buffer called *Bar*,
- On M-x foo again, with the buffer *Bar* on the left, this window is
removed.

Problem is, this can't be done with a simple split. So my first idea
was to reduce the frame to one window, split it: left would be *Bar*
and restore the window-tree in the right part.

Of course, this can't work, because if I use delete-other-windows, the
windows are ... deleted. So, can't be restored.

I can't find a way to do this simply, and I wonder if there is :-)

How would you do?

-- 
|  À quoi bon user des douzes pieds de         Michaël `Micha' Cadilhac |
|  l'alexandrin si ces dames s'épuisent     cadilh_m - Epita 2007 - CSI |
|  au premier pied qu'elles prennent ?  JID: michael.cadilhac@gmail.com |
`--  -  -         -- Jacques_Beauheurt                            - - --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: MY window tree!

[Lennart Borgman (gmail)]

Michaël Cadilhac wrote:
> Hi!
> 
> I've been playing around with window-tree to do the following :
> - On M-x foo, a window is created on the extreme left of the frame,
> containing a buffer called *Bar*,
> - On M-x foo again, with the buffer *Bar* on the left, this window is
> removed.
> 
> Problem is, this can't be done with a simple split. So my first idea
> was to reduce the frame to one window, split it: left would be *Bar*
> and restore the window-tree in the right part.
> 
> Of course, this can't work, because if I use delete-other-windows, the
> windows are ... deleted. So, can't be restored.
> 
> I can't find a way to do this simply, and I wonder if there is :-)
> 
> How would you do?


Using something like

    (window-buffer (nth 2 (car (window-tree))))

perhaps?

Re: MY window tree!

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1601 bytes --]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Michaël Cadilhac wrote:
>> Hi!
>>
>> I've been playing around with window-tree to do the following :
>> - On M-x foo, a window is created on the extreme left of the frame,
>> containing a buffer called *Bar*,
>> - On M-x foo again, with the buffer *Bar* on the left, this window is
>> removed.
>>
>> Problem is, this can't be done with a simple split. So my first idea
>> was to reduce the frame to one window, split it: left would be *Bar*
>> and restore the window-tree in the right part.
>>
>> Of course, this can't work, because if I use delete-other-windows, the
>> windows are ... deleted. So, can't be restored.
>>
>> I can't find a way to do this simply, and I wonder if there is :-)
>>
>> How would you do?
>
> Using something like
>
>    (window-buffer (nth 2 (car (window-tree))))
>
> perhaps?

Yeah, that's what I'm thinking about when I talk about « not
simple ways » :-)

This implies to parse the window-tree, and for each leaves of the
tree, which is a window, get its buffer and its size; then store it in
another tree to restore it.

Damn, I just want to create another root, this can't be that complex,
is it ?

Thanks for you advice, however :-)

-- 
 |      Michaël `Micha' Cadilhac     |   Did you Mooh today ?                 |
 |         Epita/LRDE Promo 2007     |                                        |
 |  http://michael.cadilhac.name     |       http://boitam.eu/                |
 `--JID: michael.cadilhac@gmail.com--'                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: MY window tree!

[Lennart Borgman (gmail)]

Michaël Cadilhac wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Michaël Cadilhac wrote:
>>> Hi!
>>>
>>> I've been playing around with window-tree to do the following :
>>> - On M-x foo, a window is created on the extreme left of the frame,
>>> containing a buffer called *Bar*,
>>> - On M-x foo again, with the buffer *Bar* on the left, this window is
>>> removed.
>>>
>>> Problem is, this can't be done with a simple split. So my first idea
>>> was to reduce the frame to one window, split it: left would be *Bar*
>>> and restore the window-tree in the right part.
>>>
>>> Of course, this can't work, because if I use delete-other-windows, the
>>> windows are ... deleted. So, can't be restored.
>>>
>>> I can't find a way to do this simply, and I wonder if there is :-)
>>>
>>> How would you do?
>> Using something like
>>
>>    (window-buffer (nth 2 (car (window-tree))))
>>
>> perhaps?
> 
> Yeah, that's what I'm thinking about when I talk about « not
> simple ways » :-)
> 
> This implies to parse the window-tree, and for each leaves of the
> tree, which is a window, get its buffer and its size; then store it in
> another tree to restore it.
> 
> Damn, I just want to create another root, this can't be that complex,
> is it ?
> 
> Thanks for you advice, however :-)


A little bit more simple way out might be to look for the uppermost left 
window and see if that is *Bar*.

Re: MY window tree!

[Stefan Monnier]

> A little bit more simple way out might be to look for the uppermost left
> window and see if that is *Bar*.

Or look for a window displaying buffer *Bar* and check to see if it happens
to be in the upper-left corner.


        Stefan

Re: MY window tree!

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1393 bytes --]

michael@cadilhac.name (Michaël Cadilhac) writes:

> Hi!
>
> I've been playing around with window-tree to do the following :
> - On M-x foo, a window is created on the extreme left of the frame,
> containing a buffer called *Bar*,
> - On M-x foo again, with the buffer *Bar* on the left, this window is
> removed.
>
> Problem is, this can't be done with a simple split. So my first idea
> was to reduce the frame to one window, split it: left would be *Bar*
> and restore the window-tree in the right part.
>
> Of course, this can't work, because if I use delete-other-windows, the
> windows are ... deleted. So, can't be restored.
>
> I can't find a way to do this simply, and I wonder if there is :-)
>
> How would you do?

Just to be sure there's no misunderstanding, what I try to do is :

___________
|    |    |
| 1  | 2  |
|____|____|
|         | 
|    3    |
|_________|

to become

___________
|  |  |   |
|  | 1| 2 |
| B|__|___|
| A|      | 
| R|  3   |
|__|______|

Not for the UPPER window, in fact.

TIA !

-- 
 |      Michaël `Micha' Cadilhac     |  (\(\  This is the cute bunny virus,   |
 |         Epita/LRDE Promo 2007     |  (^.^)  please copy this into your     |
 |  http://michael.cadilhac.name     |  (")")  sig so it can spread.          |
 `--JID: michael.cadilhac@gmail.com--'                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

MY window tree!

[martin rudalics]

 > I've been playing around with window-tree to do the following :
 > - On M-x foo, a window is created on the extreme left of the frame,
 > containing a buffer called *Bar*,
 > - On M-x foo again, with the buffer *Bar* on the left, this window is
 > removed.
 >
 > Problem is, this can't be done with a simple split. So my first idea
 > was to reduce the frame to one window, split it: left would be *Bar*
 > and restore the window-tree in the right part.
 >
 > Of course, this can't work, because if I use delete-other-windows, the
 > windows are ... deleted. So, can't be restored.
 >
 > I can't find a way to do this simply, and I wonder if there is :-)

Don't wonder: You first have to save the window-list of the frame
including all windows' edges and identities.  Next you have to create the
*Bar* window with the intended width and split the window on the right
in the way listed by the saved window-list, adjust the vertical dividers
proportionally to what you had before (there's always a chance that a
window drops below the minimum width now) and assign any window-local
overlays the identity of their new window.  In addition there might be
dedicated windows and other window-local properties as well ...

I once struggled a lot with the much simpler problem of a window
configuration like

  ----------
| |        |
|1|   2    |
| |        |
  ----------

I wanted to transform into

  ----------
|1|   2    |
|----------|
|   3      |
  ----------

If you come up with a solution to your problem I'd definitely want to
hear about it ;-)

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > I've been playing around with window-tree to do the following :
>  > - On M-x foo, a window is created on the extreme left of the frame,
>  > containing a buffer called *Bar*,
>  > - On M-x foo again, with the buffer *Bar* on the left, this window is
>  > removed.
>  >
>  > Problem is, this can't be done with a simple split. So my first idea
>  > was to reduce the frame to one window, split it: left would be *Bar*
>  > and restore the window-tree in the right part.
>  >
>  > Of course, this can't work, because if I use delete-other-windows, the
>  > windows are ... deleted. So, can't be restored.
>  >
>  > I can't find a way to do this simply, and I wonder if there is :-)
> 
> Don't wonder: You first have to save the window-list of the frame
> including all windows' edges and identities.  Next you have to create the
> *Bar* window with the intended width and split the window on the right
> in the way listed by the saved window-list, adjust the vertical dividers
> proportionally to what you had before (there's always a chance that a
> window drops below the minimum width now) and assign any window-local
> overlays the identity of their new window.  In addition there might be
> dedicated windows and other window-local properties as well ...
> 
> I once struggled a lot with the much simpler problem of a window
> configuration like
> 
>  ----------
> | |        |
> |1|   2    |
> | |        |
>  ----------
> 
> I wanted to transform into
> 
>  ----------
> |1|   2    |
> |----------|
> |   3      |
>  ----------
> 
> If you come up with a solution to your problem I'd definitely want to
> hear about it ;-)


I have uploaded a preliminary version of winsav.el to

   http://ourcomments.org/Emacs/DL/elisp/test/winsav.el

Re: MY window tree!

[martin rudalics]

 > I have uploaded a preliminary version of winsav.el to
 >
 >   http://ourcomments.org/Emacs/DL/elisp/test/winsav.el
 >

The problem is that the split-windows below will create *new* windows
rather than "reuse" the old ones.  Hence any overlay relationships and
other window-local things get broken by this.

       (dolist (subtree (cdddr saved-tree))
         (add-to-list 'wtree
                      (cons
                       (if ver
                           (split-window-vertically)
                         (split-window-horizontally))
                       subtree)
                      t)

IMO there's no way around retaining sequence numbers of windows when
saving and restoring window trees.  Hardly possible when done at the
Lisp level.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > I have uploaded a preliminary version of winsav.el to
>  >
>  >   http://ourcomments.org/Emacs/DL/elisp/test/winsav.el
>  >
> 
> The problem is that the split-windows below will create *new* windows
> rather than "reuse" the old ones.  Hence any overlay relationships and
> other window-local things get broken by this.

Yes, it creates new windows and window local things will get broken. But 
  I do not understand what you mean with "overlay relationships" here. 
Emacs overlays (if that is what you mean) is tighed to the buffer, not 
the window.


>       (dolist (subtree (cdddr saved-tree))
>         (add-to-list 'wtree
>                      (cons
>                       (if ver
>                           (split-window-vertically)
>                         (split-window-horizontally))
>                       subtree)
>                      t)
> 
> IMO there's no way around retaining sequence numbers of windows when
> saving and restoring window trees.  Hardly possible when done at the
> Lisp level.


Maybe, but please be more specific about what will be missing when done 
on the lisp level.

Re: MY window tree!

[Juanma Barranquero]

On 1/14/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

>   I do not understand what you mean with "overlay relationships" here.
> Emacs overlays (if that is what you mean) is tighed to the buffer, not
> the window.

>From the node "Overlay Properties" of the Emacs Lisp Reference:

`window'
     If the `window' property is non-`nil', then the overlay applies
     only on that window.

                    /L/e/k/t/u

Re: MY window tree!

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 1/14/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>>   I do not understand what you mean with "overlay relationships" here.
>> Emacs overlays (if that is what you mean) is tighed to the buffer, not
>> the window.
> 
>> From the node "Overlay Properties" of the Emacs Lisp Reference:
> 
> `window'
>     If the `window' property is non-`nil', then the overlay applies
>     only on that window.



Oh, thanks, I never noticed that. Useful.

But these overlays could of course be saved and restored too.

Re: MY window tree!

[martin rudalics]

 > Yes, it creates new windows and window local things will get broken. But
 >  I do not understand what you mean with "overlay relationships" here.
 > Emacs overlays (if that is what you mean) is tighed to the buffer, not
 > the window.

Juanma explained that already.  It can be done as

(dolist (overlay (overlays-in (point-min) (point-max)))
   (when (eq (overlay-get overlay 'window) old-window)
      (overlay-put overlay 'window new-window)))

 > Maybe, but please be more specific about what will be missing when done
 > on the lisp level.

On the Lisp level it might be difficult to handle `get-lru-window',
`buffer-display-count', `buffer-display-time', and the `keep-margins'
argument of `set-window-buffer'.  It should be possible to handle
`window-dedicated-p', `window-scroll-bars', `window-fringes' but I don't
remember them all.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > Yes, it creates new windows and window local things will get broken. But
>  >  I do not understand what you mean with "overlay relationships" here.
>  > Emacs overlays (if that is what you mean) is tighed to the buffer, not
>  > the window.
> 
> Juanma explained that already.  It can be done as
> 
> (dolist (overlay (overlays-in (point-min) (point-max)))
>   (when (eq (overlay-get overlay 'window) old-window)
>      (overlay-put overlay 'window new-window)))
> 
>  > Maybe, but please be more specific about what will be missing when done
>  > on the lisp level.
> 
> On the Lisp level it might be difficult to handle `get-lru-window',
> `buffer-display-count', `buffer-display-time', and the `keep-margins'
> argument of `set-window-buffer'.  It should be possible to handle
> `window-dedicated-p', `window-scroll-bars', `window-fringes' but I don't
> remember them all.


buffer-display-time indeed looks difficult and I would hesitate to 
change buffer-display-count. The others look possible.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > Yes, it creates new windows and window local things will get broken. But
>  >  I do not understand what you mean with "overlay relationships" here.
>  > Emacs overlays (if that is what you mean) is tighed to the buffer, not
>  > the window.
> 
> Juanma explained that already.  It can be done as
> 
> (dolist (overlay (overlays-in (point-min) (point-max)))
>   (when (eq (overlay-get overlay 'window) old-window)
>      (overlay-put overlay 'window new-window)))
> 
>  > Maybe, but please be more specific about what will be missing when done
>  > on the lisp level.
> 
> On the Lisp level it might be difficult to handle `get-lru-window',
> `buffer-display-count', `buffer-display-time', and the `keep-margins'
> argument of `set-window-buffer'.  It should be possible to handle
> `window-dedicated-p', `window-scroll-bars', `window-fringes' but I don't
> remember them all.


I believe the new version is pretty useful:

   http://ourcomments.org/Emacs/DL/elisp/test/winsav.el

Saving and restoring properties is rather straightforward. Is there 
still any reason to have this in C?

Re: MY window tree!

[Juanma Barranquero]

On 1/14/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> I believe the new version is pretty useful:

        (with-current-buffer buffer
          (save-restriction
;;; =>      (widen)
            (dolist (overlay (overlays-in (point-min) (point-max)))

I think you need widen at that point, don't you?

                    /L/e/k/t/u

Re: MY window tree!

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 1/14/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> I believe the new version is pretty useful:
> 
>        (with-current-buffer buffer
>          (save-restriction
> ;;; =>      (widen)
>            (dolist (overlay (overlays-in (point-min) (point-max)))
> 
> I think you need widen at that point, don't you?


Yes, I do. Thanks. ;-)

Re: MY window tree!

[martin rudalics]

 > Saving and restoring properties is rather straightforward. Is there
 > still any reason to have this in C?

I don't care about things like `buffer-display-count' or `use_time',
hence I wouldn't know.  I would care, however, about the following:


(1) You do

(newovl (make-overlay start end)))

but you never delete any overlays AFAICT.  Doesn't this mean to get
_two_ overlays (whose properties are mostly identical but for the
window-property) in the same place?  What's so problematic about simply
changing the window-property of each affected overlay to "window"?


(2) The adjusting part doesn't work here yet, that is all windows are
balanced in their heights and widths.  I don't understand the code yet
but I can't imagine that it should be necessary to round the size of all
windows, leaf windows should be left alone, I presume.  (BTW new-height,
new-size, ..., old-width would be more readable.)

I tried with trivial code like

   (let ((tree (winsav-get-window-tree)))
     (delete-other-windows)
     (winsav-restore-window-tree
      tree
      (split-window (selected-window) nil t)))


(3) I don't understand yet what happens when a particular window can't
be split because it's too small.


(4) I think `window-start' should be preserved unless this would make
`window-point' disappear.


(5) A hook which passes old / new window arguments for each pair where a
change took place would be urgently needed.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > Saving and restoring properties is rather straightforward. Is there
>  > still any reason to have this in C?
> 
> I don't care about things like `buffer-display-count' or `use_time',
> hence I wouldn't know.  I would care, however, about the following:
> 
> 
> (1) You do
> 
> (newovl (make-overlay start end)))
> 
> but you never delete any overlays AFAICT.  Doesn't this mean to get
> _two_ overlays (whose properties are mostly identical but for the
> window-property) in the same place?  What's so problematic about simply
> changing the window-property of each affected overlay to "window"?


Then the old window that the overlay 'window property pointed to no 
longer exists there are no problem, but if it does then I think it is 
best to copy the overlay. I have changed the code to do distinguish 
those two cases now.

See also the comment in Bugs and limitation that I have added to 
winsav.el now.


> (2) The adjusting part doesn't work here yet, that is all windows are
> balanced in their heights and widths.  I don't understand the code yet
> but I can't imagine that it should be necessary to round the size of all
> windows, leaf windows should be left alone, I presume.  (BTW new-height,
> new-size, ..., old-width would be more readable.)
> 
> I tried with trivial code like
> 
>   (let ((tree (winsav-get-window-tree)))
>     (delete-other-windows)
>     (winsav-restore-window-tree
>      tree
>      (split-window (selected-window) nil t)))


Resizing is a bit harder than one think at the beginning. I forgot that 
it must be done iteratively. I have added that now, please try again.


> (3) I don't understand yet what happens when a particular window can't
> be split because it's too small.


I had not try taken care of that problem before. I have tried to do that 
now.


> (4) I think `window-start' should be preserved unless this would make
> `window-point' disappear.


Seems reasonable. I have tried to fix it.


> (5) A hook which passes old / new window arguments for each pair where a
> change took place would be urgently needed.


I do not see where to put in the hook. Maybe returning a list of window 
pairs ((old new) ...) would do what you want?

Re: MY window tree!

[Juanma Barranquero]

>From your package:

;; Juanma Barranquero has pointed out there is a serious limitation in
;; this way of doing it when overlays with 'window properties are
;; used. The problem is that any pointers to windows are made invalid
;; since they are deleted. So in fact any code that relies on saved
;; pointers to windows will have problem if the window is one of those
;; that are involved here.

I was talking of modes that maintain a list of *overlays*, not
windows, but this other point, though not mine, is also valid :)

All in all, I think all this is complicated stuff for something that
would perhaps be easier at the C level, without the need to delete and
recreate windows.

                    /L/e/k/t/u

Re: MY window tree!

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
>> From your package:
> 
> ;; Juanma Barranquero has pointed out there is a serious limitation in
> ;; this way of doing it when overlays with 'window properties are
> ;; used. The problem is that any pointers to windows are made invalid
> ;; since they are deleted. So in fact any code that relies on saved
> ;; pointers to windows will have problem if the window is one of those
> ;; that are involved here.
> 
> I was talking of modes that maintain a list of *overlays*, not
> windows, but this other point, though not mine, is also valid :)


But overlays are bound to buffers AFAIK. I can not see there are any 
problems with buffers here. Or am I missing something?

Is not the only binding from overlays to windows the 'window property 
that can be set for some overlays.


> All in all, I think all this is complicated stuff for something that
> would perhaps be easier at the C level, without the need to delete and
> recreate windows.


I am not sure if it is very easy at the C level, but it would be good to 
have primitives for handling cases like this there.

Re: MY window tree!

[Juanma Barranquero]

On 1/15/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> But overlays are bound to buffers AFAIK. I can not see there are any
> problems with buffers here. Or am I missing something?

Buffer B's mode, A-mode, has functions to create and maintain a list
of overlays, O1..ON, some of which have a 'window property. You change
windows and copy a subset of O1..ON, O'M..O'K. Now the buffer has
overlays A-mode knows nothing about. If A-mode has, for example, a
command to move some subset of O1..ON, it will leave behind O'M..O'K
even if they're copies of some of the ones moved.

The problem is that by creating new overlays you're bypassing A-mode's
expectations about what B contains. If B detects the overlays by
searching them, fine. But B can use shortcuts like lists, or perhaps
hash tables.

> Is not the only binding from overlays to windows the 'window property
> that can be set for some overlays.

Perhaps, but I'm talking of the binding from overlays to buffers to
mode functions that manipulate them.

> but it would be good to
> have primitives for handling cases like this there.

Agreed. (After The Release And Other Usual Disclaimers)

                    /L/e/k/t/u

Re: MY window tree!

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 1/15/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> But overlays are bound to buffers AFAIK. I can not see there are any
>> problems with buffers here. Or am I missing something?
> 
> Buffer B's mode, A-mode, has functions to create and maintain a list
> of overlays, O1..ON, some of which have a 'window property. You change
> windows and copy a subset of O1..ON, O'M..O'K. Now the buffer has
> overlays A-mode knows nothing about. If A-mode has, for example, a
> command to move some subset of O1..ON, it will leave behind O'M..O'K
> even if they're copies of some of the ones moved.
> 
> The problem is that by creating new overlays you're bypassing A-mode's
> expectations about what B contains. If B detects the overlays by
> searching them, fine. But B can use shortcuts like lists, or perhaps
> hash tables.


I have actually changed that to just change the 'window property of the 
overlays. No overlays are normally copied any more. If the window object 
that the 'window properties points to is not a valid window any more 
then I just replace that value with a pointer to the new window that 
have replaced the old one.

I guess that for most cases this will be sufficient. But there can still 
be cases where a mode (or some other code) have a persisting pointer to 
a window object. I can not replace this pointers.

I would suspect that this situation is not very common, but I am not 
sure. I am not aware of any such case at all so please tell me so I can 
get a better picture of this.


>> Is not the only binding from overlays to windows the 'window property
>> that can be set for some overlays.
> 
> Perhaps, but I'm talking of the binding from overlays to buffers to
> mode functions that manipulate them.
> 
>> but it would be good to
>> have primitives for handling cases like this there.
> 
> Agreed. (After The Release And Other Usual Disclaimers)
> 
>                    /L/e/k/t/u
> 

Re: MY window tree!

[Juanma Barranquero]

On 1/15/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> I have actually changed that to just change the 'window property of the
> overlays. No overlays are normally copied any more.

Ah, good.

> If the window object
> that the 'window properties points to is not a valid window any more
> then I just replace that value with a pointer to the new window that
> have replaced the old one.

I think the right thing to do would be a bit more complicate:

 1) search every displayed buffer and make a list of all overlays
associated to windows, and which windows are they associated to (one
list for window, I suppose).
 2) do your mumbo-jumbo with windows
 3) determine which window corresponds to every buffer now
 4) process the lists of 1) above and modify only those overlays that
pointed to a non-alive windows W1 that corresponds now to W2.

All this because there may be other valid reasons why a buffer
contains overlays with 'window properties pointing to a dead window.
You don't want them suddenly being visible in the wrong window, do
you?

> I guess that for most cases this will be sufficient. But there can still
> be cases where a mode (or some other code) have a persisting pointer to
> a window object. I can not replace this pointers.

Of course.

> I would suspect that this situation is not very common, but I am not
> sure. I am not aware of any such case at all so please tell me so I can
> get a better picture of this.

I'm no aware either. I'm just pointing out that there's a reason this
hasn't been done earlier in elisp :)

                    /L/e/k/t/u

Re: MY window tree!

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 1/15/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> I have actually changed that to just change the 'window property of the
>> overlays. No overlays are normally copied any more.
> 
> Ah, good.
> 
>> If the window object
>> that the 'window properties points to is not a valid window any more
>> then I just replace that value with a pointer to the new window that
>> have replaced the old one.
> 
> I think the right thing to do would be a bit more complicate:
> 
> 1) search every displayed buffer and make a list of all overlays
> associated to windows, and which windows are they associated to (one
> list for window, I suppose).
> 2) do your mumbo-jumbo with windows
> 3) determine which window corresponds to every buffer now
> 4) process the lists of 1) above and modify only those overlays that
> pointed to a non-alive windows W1 that corresponds now to W2.


You are right, I have to check more buffers. In fact every buffer, 
displayed or not. Done.


I introduced some bugs when I tried to fix the resizing. Hope I got 
everything in the right place now.

Re: MY window tree!

[martin rudalics]

 > I have actually changed that to just change the 'window property of the
 > overlays. No overlays are normally copied any more. If the window object
 > that the 'window properties points to is not a valid window any more
 > then I just replace that value with a pointer to the new window that
 > have replaced the old one.

I'm using this concept for two years now and it never failed (I suppose
because a window can't be collected as long as an overlay references
it).

 > I guess that for most cases this will be sufficient. But there can still
 > be cases where a mode (or some other code) have a persisting pointer to
 > a window object. I can not replace this pointers.

Never mind.  `window-configuration-change-hook' must handle this.  Any
mode referencing a window object must be aware of the fact that the user
may delete the window and recreate another one showing the same buffer
whenever she wants to.  When one window replaces another the
configuration changes and the mode should be able to handle this.

In some cases it might be, however, reasonable to advert the mode that
the window has been resurrected.  Hence, what's needed are two hooks: A
`before-winsav' or so hook (which tells the mode designer to not run any
configuration change hooks) and an `after-winsav' hook.  The latter
would have to be called with a list of old-window/new-window
correspondences (again I suppose that windows are not collected as long
as they are referenced from that list).

Re: MY window tree!

[martin rudalics]

 >> 1) search every displayed buffer and make a list of all overlays
 >> associated to windows, and which windows are they associated to (one
 >> list for window, I suppose).
 >> 2) do your mumbo-jumbo with windows
 >> 3) determine which window corresponds to every buffer now
 >> 4) process the lists of 1) above and modify only those overlays that
 >> pointed to a non-alive windows W1 that corresponds now to W2.
 >
 >
 >
 > You are right, I have to check more buffers. In fact every buffer,
 > displayed or not. Done.

Why check all buffers?  Juanma's recipe was precise in my opinion.  Note
that buffers may have overlays for windows that are no more live.  These
overlays are useless and prevent the windows from being collected.  They
are harmless, though.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:

> Why check all buffers?  Juanma's recipe was precise in my opinion.  Note
> that buffers may have overlays for windows that are no more live.  These
> overlays are useless and prevent the windows from being collected.  They
> are harmless, though.

I can not see why only displayed buffers should be interesting. A buffer 
that is not currently displayed could also have a 'window property 
pointing to some of those windows we are interested in. Or?

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > I have actually changed that to just change the 'window property of the
>  > overlays. No overlays are normally copied any more. If the window object
>  > that the 'window properties points to is not a valid window any more
>  > then I just replace that value with a pointer to the new window that
>  > have replaced the old one.
> 
> I'm using this concept for two years now and it never failed (I suppose
> because a window can't be collected as long as an overlay references
> it).
> 
>  > I guess that for most cases this will be sufficient. But there can still
>  > be cases where a mode (or some other code) have a persisting pointer to
>  > a window object. I can not replace this pointers.
> 
> Never mind.  `window-configuration-change-hook' must handle this.  Any
> mode referencing a window object must be aware of the fact that the user
> may delete the window and recreate another one showing the same buffer
> whenever she wants to.  When one window replaces another the
> configuration changes and the mode should be able to handle this.
> 
> In some cases it might be, however, reasonable to advert the mode that
> the window has been resurrected.  Hence, what's needed are two hooks: A
> `before-winsav' or so hook (which tells the mode designer to not run any
> configuration change hooks) and an `after-winsav' hook.  The latter
> would have to be called with a list of old-window/new-window
> correspondences (again I suppose that windows are not collected as long
> as they are referenced from that list).


Ok, now I see what you mean with the hooks. I will add it in a minute.

But there is one thing I do not understand. "Collected" above is that 
garbage collected? Do you mean that the window object is available and 
not garbage collected until some time after all elisp pointers to it are 
gone?

How does window-live-p fit into this? The doc string a bit cryptic says

   Returns t if object is a window which is currently visible.

Is an invisible window object a window that has elisp pointers to it, 
but is not on any frame? (And can never more be on any fram AFAIU.)

Re: MY window tree!

[martin rudalics]

 > I can not see why only displayed buffers should be interesting. A buffer
 > that is not currently displayed could also have a 'window property
 > pointing to some of those windows we are interested in. Or?

No.  A dead window is never resurrected.  The window property of that
overlay is of no use until you reassign it the value of a live window.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:

> In some cases it might be, however, reasonable to advert the mode that
> the window has been resurrected.  Hence, what's needed are two hooks: A
> `before-winsav' or so hook (which tells the mode designer to not run any
> configuration change hooks) and an `after-winsav' hook.  The latter
> would have to be called with a list of old-window/new-window
> correspondences (again I suppose that windows are not collected as long
> as they are referenced from that list).


I have tried to add the hooks on reasonable places. I would be glad for 
some comments on that.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > I can not see why only displayed buffers should be interesting. A buffer
>  > that is not currently displayed could also have a 'window property
>  > pointing to some of those windows we are interested in. Or?
> 
> No.  A dead window is never resurrected.  The window property of that
> overlay is of no use until you reassign it the value of a live window.


Maybe we are miscommunicating. I am talking about displayed BUFFERS 
while I wonder if you and Juanma perhaps talks about displayed WINDOWS.

Or am I misunderstanding something?

Re: MY window tree!

[martin rudalics]

 > But there is one thing I do not understand. "Collected" above is that
 > garbage collected? Do you mean that the window object is available and
 > not garbage collected until some time after all elisp pointers to it are
 > gone?

As long as I have a pointer to it the window object should be available,
otherwise the pointer would dangle.  That is, the collector should not
be allowed to reclaim that window object.

 >
 > How does window-live-p fit into this? The doc string a bit cryptic says
 >
 >   Returns t if object is a window which is currently visible.
 >
 > Is an invisible window object a window that has elisp pointers to it,
 > but is not on any frame? (And can never more be on any fram AFAIU.)

I think a window is live as long as it has an associated buffer.  After
a window has lost its buffer it's still a window but it cannot be on a
frame any more.

Re: MY window tree!

[martin rudalics]

 >>  > I can not see why only displayed buffers should be interesting. A
 >> buffer
 >>  > that is not currently displayed could also have a 'window property
 >>  > pointing to some of those windows we are interested in. Or?
 >>
 >> No.  A dead window is never resurrected.  The window property of that
 >> overlay is of no use until you reassign it the value of a live window.
 >
 >
 >
 > Maybe we are miscommunicating. I am talking about displayed BUFFERS
 > while I wonder if you and Juanma perhaps talks about displayed WINDOWS.
 >
 > Or am I misunderstanding something?

Above you said "a buffer ... could have a 'window property".  I don't
know of such a property of a buffer.  I've been always talking about
overlays with a 'window property.  Overlays belong to a buffer.  Note
that a buffer can have two or more overlays with different window
properties.  Hence the buffer's text may appear differently when it is
simultaneously displayed in two windows.  When I remove the 'window
property from an overlay the overlay should appear in all windows
displaying the buffer the overlay belongs to.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  >>  > I can not see why only displayed buffers should be interesting. A
>  >> buffer
>  >>  > that is not currently displayed could also have a 'window property
>  >>  > pointing to some of those windows we are interested in. Or?
>  >>
>  >> No.  A dead window is never resurrected.  The window property of that
>  >> overlay is of no use until you reassign it the value of a live window.
>  >
>  >
>  >
>  > Maybe we are miscommunicating. I am talking about displayed BUFFERS
>  > while I wonder if you and Juanma perhaps talks about displayed WINDOWS.
>  >
>  > Or am I misunderstanding something?
> 
> Above you said "a buffer ... could have a 'window property".  I don't
> know of such a property of a buffer.  I've been always talking about
> overlays with a 'window property.  Overlays belong to a buffer.  Note
> that a buffer can have two or more overlays with different window
> properties.  Hence the buffer's text may appear differently when it is
> simultaneously displayed in two windows.  When I remove the 'window
> property from an overlay the overlay should appear in all windows
> displaying the buffer the overlay belongs to.


Sorry, I should have written "A buffer that is not currently displayed 
IN ANY WINDOW could also have AN OVERLAY WITH a 'window property...".

This was supposed to be the answer to your question "Why check all 
buffers?" - I still do not understand what you mean here. Did you want 
to write all WINDOWS?

Re: MY window tree!

[martin rudalics]

 > I have tried to add the hooks on reasonable places. I would be glad for
 > some comments on that.

`winsav-after-get' and `winsav-after-put' should be defvard and the args
documented.  I'd also rename them to `before-winsav-functions' and
`after-winsav-functions' (compare `before-revert-hook' and
`after-revert-hook'), Juanma knows the naming conventions better.

But I notice that you still make overlays.  I thought we convinced you
they are not needed.  Believe me: The only case you should care about is
when an overlay has a 'window property referencing a window that has an
ovlwin-window association.  Investigating _all_ overlays in _all_ live
buffers is overkill and would make this very slow.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > I have tried to add the hooks on reasonable places. I would be glad for
>  > some comments on that.
> 
> `winsav-after-get' and `winsav-after-put' should be defvard and the args
> documented.  I'd also rename them to `before-winsav-functions' and
> `after-winsav-functions' (compare `before-revert-hook' and
> `after-revert-hook'), Juanma knows the naming conventions better.

Thanks. I think hooks ending in "-hook" by convention is called with no 
arguments. "-hooks" seems good here. I like to have the library name in 
the beginning of the name.

I have changed the names and defvared them.


> But I notice that you still make overlays.  I thought we convinced you
> they are not needed.  Believe me: The only case you should care about is
> when an overlay has a 'window property referencing a window that has an
> ovlwin-window association.  Investigating _all_ overlays in _all_ live
> buffers is overkill and would make this very slow.


No, you have not convinced me - I do not believe we have disagreed ;-)

In the normal use case no overlays should be made (see the beginning of 
the file). However I think my check for if the old window is still a 
window on a frame was wrong. I checked only window-live-p. I have added 
a check of window-frame now.

But I do not understand what you and Juanma tries to say. Is there 
perhaps another way to find the overlays than using overlays-in? I am 
not aware of any other way, but perhaps you are?

If not so, then do I not have to look at all overlays in all buffers? I 
do not know if this is actually a problem, but if it is then it is a 
good point in favor for a solution in C. However I do not expect the 
functions in winsav.el to be called very frequently.

Re: MY window tree!

[martin rudalics]

 > If not so, then do I not have to look at all overlays in all buffers?

You should look only at the overlays of buffers whose windows have
"changed".  That is, all buffers where a ovlwin-window association
exists such that window displays the buffer.

I think that after running winsav to its end you have four cases:

   The window existed before and exists now.  Ignore it. It's the same
   window and any overlays referencing it before still reference it.

   The window did not exist before but exists now.  Since you do not
   arbitrarily create new windows there must be a ovlwin-window
   association and the associated buffer's overlays may have to be
   updated.

   The window existed before and doesn't exist now (probably because it
   was discarded during splitting).  Ignore it.  Any overlay referencing
   that window won't be displayed in any other window.

   The window didn't exist before and doesn't now.  Ignore it trivially.

Note: An existing buffer cannot have an overlay referencing a window
you create.

 > I do not know if this is actually a problem, but if it is then it is a
 > good point in favor for a solution in C. However I do not expect the
 > functions in winsav.el to be called very frequently.

Initially you didn't want to bother about overlays at all, now you want
to check overlays in all buffers.  Initially you wanted to convince me
that you can do it in Lisp, now that you have nearly done it, you favor
a solution in C.  Alas, this will be hardly ever done in C, the window
related code is too hairy.  Yours could be perfect (if you just removed
the make-overlay stuff).

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > If not so, then do I not have to look at all overlays in all buffers?
> 
> You should look only at the overlays of buffers whose windows have
> "changed".  That is, all buffers where a ovlwin-window association
> exists such that window displays the buffer.
> 
> I think that after running winsav to its end you have four cases:
> 
>   The window existed before and exists now.  Ignore it. It's the same
>   window and any overlays referencing it before still reference it.
> 
>   The window did not exist before but exists now.  Since you do not
>   arbitrarily create new windows there must be a ovlwin-window
>   association and the associated buffer's overlays may have to be
>   updated.
> 
>   The window existed before and doesn't exist now (probably because it
>   was discarded during splitting).  Ignore it.  Any overlay referencing
>   that window won't be displayed in any other window.
> 
>   The window didn't exist before and doesn't now.  Ignore it trivially.


Maybe you are saying something that I am missing, but I believe I am 
doing what you propose already. Some questions/points to see if we agree:

1) I think I must search all buffers
2) I must check all overlays in these buffers
3) The only thing I have to check in the overlays is the 'window prop
4) I only have to care if the prop value is a window in the saved tree
5) If that window is not on a frame any more I just replace the value
6) Otherwise I make a new overlay -- seldom

The above is what I am doing. Is any of those points incorrect in your 
opinion? Here is the code:

     (dolist (buf (buffer-list))
       (with-current-buffer buf
         (save-restriction
           (widen)
           (dolist (overlay (overlays-in (point-min) (point-max)))
             (when (setq ovlwin (car (memq (overlay-get overlay 'window) 
oldwins)))
               (setq window (cadr (assoc ovlwin win-list)))
               ;; If the old window is still alive then copy overlay,
               ;; otherwise change the 'window prop.
               (if (not (and (window-live-p ovlwin)
                             (window-frame ovlwin)))
                    ....

`oldwins' is a list with the old windows, ie the windows in the saved tree.

> Initially you didn't want to bother about overlays at all, now you want
> to check overlays in all buffers.  

True, I was not aware of that they could point to windows.

> Initially you wanted to convince me
> that you can do it in Lisp, now that you have nearly done it, you favor
> a solution in C.  

In the short term I think this solution is good enough. And it actually 
can do a bit more than a solution in C that gives handles to manipulate 
the internal C window tree.

> Alas, this will be hardly ever done in C, the window
> related code is too hairy.  


I believe it would be possible to right code to manipulate the internal 
tree as above. A solution building on that would probably use the 
resizing part from my elisp solution (or something similar).

> Yours could be perfect (if you just removed
> the make-overlay stuff).

It could be Good Enough ;-)

Re: MY window tree!

[martin rudalics]

 > 1) I think I must search all buffers

No.  Only the buffers that have an ovlwin-window association.

 > 2) I must check all overlays in these buffers

Yes (unfortunately) but _only_ in the buffers mentioned above.

 > 3) The only thing I have to check in the overlays is the 'window prop

Yes.

 > 4) I only have to care if the prop value is a window in the saved tree

Yes.

 > 5) If that window is not on a frame any more I just replace the value

Together steps 1) and 4) assert that the window is not on a frame any
more, hence, you don't have to check this.

 > 6) Otherwise I make a new overlay -- seldom

_Never_ make a new overlay.

 > The above is what I am doing. Is any of those points incorrect in your
 > opinion? Here is the code:
 >
 >     (dolist (buf (buffer-list))

`buffer-list' is bad.  I'd use something like

(dolist (buf (let (buffer buffers)
	       (dolist (win win-list buffers)
	         ;; I presume cadr refers to the "new" window.
		 (setq buffer (window-buffer (cadr win)))
		 (unless (memq buffer buffers)
		   (setq buffers (cons buffer buffers))))))
   ...

 >       (with-current-buffer buf
 >         (save-restriction
 >           (widen)
 >           (dolist (overlay (overlays-in (point-min) (point-max)))
 >             (when (setq ovlwin (car (memq (overlay-get overlay 'window)
 > oldwins)))
 >               (setq window (cadr (assoc ovlwin win-list)))
 >               ;; If the old window is still alive then copy overlay,
 >               ;; otherwise change the 'window prop.

This should be something along the (100% incorrect)

(dolist (overlay (overlays-in (point-min) (point-max)))
   (when (setq window (cadr (assoc (overlay-get overlay 'window))
			   win-list))
     (overlay-put overlay 'window window)))

If the old window is still alive don't do anything.  Windows that
survived the reconfiguration should not be on `win-list'.

 >               (if (not (and (window-live-p ovlwin)
 >                             (window-frame ovlwin)))
 >                    ....
 >
 > `oldwins' is a list with the old windows, ie the windows in the saved tree.

 > I believe it would be possible to right code to manipulate the internal
 > tree as above. A solution building on that would probably use the
 > resizing part from my elisp solution (or something similar).

The only time and space consuming operation is finding the overlays and
changing their property.  There's nothing you can do about that.  Note
that current solutions (like `edebug-current-windows') ignore overlays
(and many other things like dedicated windows) completely.  This could
be corrected with your algorithm, provided the save/restore step occurs
smoothly.

For `desktop-save', on the other hand, you should think of an option to
ignore overlays, though.  Storing overlays on disk is hardly conceivable
as long as we don't even bother to save text properties.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:

Hi Martin, thanks for answering so that we can clear this out. But I 
still think we are misunderstanding each other a little bit. Please see 
if my answers below.


>  > 1) I think I must search all buffers
> 
> No.  Only the buffers that have an ovlwin-window association.


There is unfortunately no way to find out if a buffer have that without 
looking at the overlays in the buffer AFAICS.


>  > 2) I must check all overlays in these buffers
> 
> Yes (unfortunately) but _only_ in the buffers mentioned above.
> 
>  > 3) The only thing I have to check in the overlays is the 'window prop
> 
> Yes.
> 
>  > 4) I only have to care if the prop value is a window in the saved tree
> 
> Yes.
> 
>  > 5) If that window is not on a frame any more I just replace the value
> 
> Together steps 1) and 4) assert that the window is not on a frame any
> more, hence, you don't have to check this.


If you are thinking of the normal use case (which is adding a BAR 
window, see winsav.el) you are right, but there may be other ways to use 
this too. In those cases the old windows may still be there on the old 
frame. (The user of these functions may for some reason be copying the 
window structure somewhere else. Do not ask me why, but the possibility 
to do that is there.)


>  > 6) Otherwise I make a new overlay -- seldom
> 
> _Never_ make a new overlay.


Yes, never in the normal use case.


>  > The above is what I am doing. Is any of those points incorrect in your
>  > opinion? Here is the code:
>  >
>  >     (dolist (buf (buffer-list))
> 
> `buffer-list' is bad.  I'd use something like
> 
> (dolist (buf (let (buffer buffers)
>            (dolist (win win-list buffers)
>              ;; I presume cadr refers to the "new" window.
>          (setq buffer (window-buffer (cadr win)))
>          (unless (memq buffer buffers)
>            (setq buffers (cons buffer buffers))))))
>   ...


Why should I only investigate those buffers?


> If the old window is still alive don't do anything.  Windows that
> survived the reconfiguration should not be on `win-list'.


In the normal use case what you are saying is correct, but there may be 
other cases.


>  > I believe it would be possible to right code to manipulate the internal
>  > tree as above. A solution building on that would probably use the
>  > resizing part from my elisp solution (or something similar).
> 
> The only time and space consuming operation is finding the overlays and
> changing their property.  There's nothing you can do about that.  Note
> that current solutions (like `edebug-current-windows') ignore overlays
> (and many other things like dedicated windows) completely.  This could
> be corrected with your algorithm, provided the save/restore step occurs
> smoothly.


If so that would be good of course.


> For `desktop-save', on the other hand, you should think of an option to
> ignore overlays, though.  Storing overlays on disk is hardly conceivable
> as long as we don't even bother to save text properties.


Yes, thanks, I have thought of that and just asked the maintainer of 
desktop.el if he is interested.

Re: MY window tree!

[martin rudalics]

 >>  > 1) I think I must search all buffers
 >>
 >> No.  Only the buffers that have an ovlwin-window association.
 >
 >
 >
 > There is unfortunately no way to find out if a buffer have that without
 > looking at the overlays in the buffer AFAICS.

It's all in the loop below where you ask "Why should I only investigate
those buffers?"

 >>  > 5) If that window is not on a frame any more I just replace the value
 >>
 >> Together steps 1) and 4) assert that the window is not on a frame any
 >> more, hence, you don't have to check this.
 >
 >
 >
 > If you are thinking of the normal use case (which is adding a BAR
 > window, see winsav.el) you are right, but there may be other ways to use
 > this too. In those cases the old windows may still be there on the old
 > frame. (The user of these functions may for some reason be copying the
 > window structure somewhere else. Do not ask me why, but the possibility
 > to do that is there.)

Why not?  The primary purpose of the 'window property is to make the
overlay appear in one and only one window.  Copying the window tree
somewhere else should move the overlay to a new window iff the old
window were deleted.  Perfectly valid.  Copying again from the saved
configuration would not see the overlay any more because it now names
another window.  Valid too.

If you really see a need to copy overlays make it optional.  In any case
there's no need to scan the entire `buffer-list' for overlays.  Any
buffer involved must have been displayed by the old window-tree and must
be displayed by the new window-tree.

Finally, if you really want to separate saving from restoring you have
to decide what to do with buffers that have been changed (window-point
or window-start are no longer valid) or deleted in the meantime.

The current problem is that of making non-orthodox window splitting as
transparent as possible.  That is, the user should not notice that you
delete and create any other windows but the very one she wanted to add.
I'd even suggest to write a `split-root-of-window-tree' command that
hides the saving and restoring stuff completely, 'horizontal non-nil
means add the new window on the left, nil at the bottom.  Interactively,
the buffer displayed in the new window would be that of the selected
window which also designates the root of the window-tree.

 >> (dolist (buf (let (buffer buffers)
 >>            (dolist (win win-list buffers)
 >>              ;; I presume cadr refers to the "new" window.
 >>          (setq buffer (window-buffer (cadr win)))
 >>          (unless (memq buffer buffers)
 >>            (setq buffers (cons buffer buffers))))))
 >>   ...
 >
 >
 >
 > Why should I only investigate those buffers?

Because people may have hundred buffers or more, many of them with
overlays.  Most overlays don't have a window property.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:

> Why not?  The primary purpose of the 'window property is to make the
> overlay appear in one and only one window.  Copying the window tree
> somewhere else should move the overlay to a new window iff the old
> window were deleted.  Perfectly valid.  Copying again from the saved
> configuration would not see the overlay any more because it now names
> another window.  Valid too.
> 
> If you really see a need to copy overlays make it optional.


OK, I have done that.


> In any case
> there's no need to scan the entire `buffer-list' for overlays.  Any
> buffer involved must have been displayed by the old window-tree and must
> be displayed by the new window-tree.


I can not see that a buffer that the buffer must have been displayed by 
the old window-tree. The 'window property might just be there to be 
shown later when the buffer is displayed in that special window.


> Finally, if you really want to separate saving from restoring you have
> to decide what to do with buffers that have been changed (window-point
> or window-start are no longer valid) or deleted in the meantime.


Good thought, thanks. I have added that.


>  > Why should I only investigate those buffers?
> 
> Because people may have hundred buffers or more, many of them with
> overlays.  Most overlays don't have a window property.


OK, I have made it an option. By default I only investigate those 
windows that you and Juanma has suggested.

Re: MY window tree!

[martin rudalics]

 >> In any case
 >> there's no need to scan the entire `buffer-list' for overlays.  Any
 >> buffer involved must have been displayed by the old window-tree and must
 >> be displayed by the new window-tree.
 >
 >
 >
 > I can not see that a buffer that the buffer must have been displayed by
 > the old window-tree. The 'window property might just be there to be
 > shown later when the buffer is displayed in that special window.

But where does the "special window" come from?

Case 1: The special window was created by `winsav-put-window-tree'.  In
this case you set the overlay property to the special window.

Case 2: The special window was not created by `winsav-put-window-tree'.
In this case the special window must have existed before calling
`winsav-put-window-tree' and there's no need to change the value of the
property.  If the property references the window it can be displayed.
Otherwise it was not displayed before and will not be afterwards.

A window property is not clairvoyant.  It may reasonably reference only
a window that exists at the time you assign the property.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  >> In any case
>  >> there's no need to scan the entire `buffer-list' for overlays.  Any
>  >> buffer involved must have been displayed by the old window-tree and 
> must
>  >> be displayed by the new window-tree.
>  >
>  >
>  >
>  > I can not see that a buffer that the buffer must have been displayed by
>  > the old window-tree. The 'window property might just be there to be
>  > shown later when the buffer is displayed in that special window.
> 
> But where does the "special window" come from?
> 
> Case 1: The special window was created by `winsav-put-window-tree'.  In
> this case you set the overlay property to the special window.
> 
> Case 2: The special window was not created by `winsav-put-window-tree'.
> In this case the special window must have existed before calling
> `winsav-put-window-tree' and there's no need to change the value of the
> property.  If the property references the window it can be displayed.
> Otherwise it was not displayed before and will not be afterwards.
> 
> A window property is not clairvoyant.  It may reasonably reference only
> a window that exists at the time you assign the property.


How does this relate to if the buffer was DISPLAYED in the window tree 
(ie if window-buffer had that value for any window in the window tree) 
at the moment winsav-get-window-tree was called?

Re: MY window tree!

[martin rudalics]

 > How does this relate to if the buffer was DISPLAYED in the window tree
 > (ie if window-buffer had that value for any window in the window tree)
 > at the moment winsav-get-window-tree was called?

If I understand correctly you save the identity of such a buffer via

         (list (window-buffer tree)

hence you have an entry for that buffer in the saved window tree.  Let's
call the buffer B and the window W.  Suppose now you eventually want to
`winsav-put-window-tree' the tree you saved.  When you create the new
window, say N, corresponding to W you make it display B (provided B
still exists).  Next you check all windows in the new window tree.  When
you check N you know that it (1) displays buffer B, and (2) is a replica
of window W.  Now you scan B and for any overlay in B referencing W you
make the overlay reference N unless W is still alive.  All other
overlays in B are ignored.  Where is the problem?  Try to describe a
scenario that introduces an inconsistency in my proposal.

Re: MY window tree!

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > How does this relate to if the buffer was DISPLAYED in the window tree
>  > (ie if window-buffer had that value for any window in the window tree)
>  > at the moment winsav-get-window-tree was called?
> 
> If I understand correctly you save the identity of such a buffer via
> 
>         (list (window-buffer tree)
> 
> hence you have an entry for that buffer in the saved window tree.  Let's
> call the buffer B and the window W.  Suppose now you eventually want to
> `winsav-put-window-tree' the tree you saved.  When you create the new
> window, say N, corresponding to W you make it display B (provided B
> still exists).  Next you check all windows in the new window tree.  When
> you check N you know that it (1) displays buffer B, and (2) is a replica
> of window W.  Now you scan B and for any overlay in B referencing W you
> make the overlay reference N unless W is still alive.  All other
> overlays in B are ignored.  Where is the problem?  Try to describe a
> scenario that introduces an inconsistency in my proposal.


The scenario is simply that at the time when I save the window tree the 
buffer with 'window property pointing to window W is not displayed in 
any window at all, but it can be displayed in window W.

Re: MY window tree!

[martin rudalics]

 > The scenario is simply that at the time when I save the window tree the
 > buffer with 'window property pointing to window W is not displayed in
 > any window at all, but it can be displayed in window W.

If the buffer was not displayed when you did `winsav-get-window-tree' it
won't figure in the saved window tree.  How can that buffer get into the
window tree when you do `winsav-put-window-tree'?