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