help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MY window tree!


From: Lennart Borgman (gmail)
Subject: Re: MY window tree!
Date: Mon, 15 Jan 2007 18:56:18 +0100
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]