From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.help Subject: Re: MY window tree! Date: Mon, 15 Jan 2007 18:26:26 +0100 Message-ID: <45ABB942.9070407@gmx.at> 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> 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 1168887616 21783 80.91.229.12 (15 Jan 2007 19:00:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2007 19:00:16 +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 20:00:14 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 1H6Vo1-0001Qz-OY for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Jan 2007 18:39:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6Vo1-0000M8-Hz for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Jan 2007 12:39:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H6VlD-00056W-5l for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 12:36:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H6Vl8-0004yK-CA for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 12:36:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6Vl7-0004xS-S0 for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 12:36:37 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1H6Vl6-0002vJ-Oe for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 12:36:37 -0500 Original-Received: (qmail invoked by alias); 15 Jan 2007 17:36:32 -0000 Original-Received: from unknown (EHLO [62.47.52.154]) [62.47.52.154] by mail.gmx.net (mp036) with SMTP; 15 Jan 2007 18:36:32 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: "Lennart Borgman (gmail)" In-Reply-To: <45AB92A8.7030300@gmail.com> X-Y-GMX-Trusted: 0 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:40318 Archived-At: > 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).