From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.help Subject: Re: MY window tree! Date: Mon, 15 Jan 2007 18:56:18 +0100 Message-ID: <45ABC042.9070707@gmail.com> References: <45A8B034.8020301@gmx.at> <45AA17CE.9050009@gmail.com> <45AA6B59.30203@gmx.at> <45AAA21C.6090505@gmail.com> <45AAB98F.8060404@gmail.com> <45AB2CDB.1040207@gmx.at> <45AB7C99.6050002@gmail.com> <45AB8B1F.7010408@gmail.com> <45AB92A8.7030300@gmail.com> <45ABB942.9070407@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1168891751 22362 80.91.229.12 (15 Jan 2007 20:09:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2007 20:09:11 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, michael@cadilhac.name Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jan 15 21:09:08 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H6WfZ-0005q5-G7 for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Jan 2007 19:34:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6WfZ-0004mq-9r for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Jan 2007 13:34:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H6Wct-0003ST-Ud for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 13:32:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H6Wct-0003Rz-4r for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 13:32:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6Wcs-0003Rn-RV for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 13:32:10 -0500 Original-Received: from [80.76.149.212] (helo=ch-smtp01.sth.basefarm.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1H6W4A-0000FN-Gy for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 12:56:20 -0500 Original-Received: from c83-254-145-24.bredband.comhem.se ([83.254.145.24]:61799 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1H6W47-00022M-5W; Mon, 15 Jan 2007 18:56:16 +0100 User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) Original-To: martin rudalics In-Reply-To: <45ABB942.9070407@gmx.at> X-Antivirus: avast! (VPS 0703-1, 2007-01-15), Outbound message X-Antivirus-Status: Clean X-Scan-Result: No virus found in message 1H6W47-00022M-5W. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1H6W47-00022M-5W 32e988425dce0887df8920646ffc130f X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:40327 Archived-At: 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.)