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: Tue, 16 Jan 2007 15:23:42 +0100 Message-ID: <45ACDFEE.8020608@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> <45ABB942.9070407@gmx.at> <45ABC474.3010208@gmail.com> <45ABD474.9040206@gmx.at> <45ABE387.9010306@gmail.com> <45AC03E2.5080109@gmx.at> <45AC18F4.4@gmail.com> <45AC82D1.1050609@gmx.at> <45ACA9C6.40400@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 1168957655 20053 80.91.229.12 (16 Jan 2007 14:27:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 Jan 2007 14:27:35 +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 Tue Jan 16 15:27:32 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 1H6pHY-0005yF-1s for geh-help-gnu-emacs@m.gmane.org; Tue, 16 Jan 2007 15:27:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6pHX-0000q7-Rm for geh-help-gnu-emacs@m.gmane.org; Tue, 16 Jan 2007 09:27:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H6pEX-0006Ke-Ip for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 09:24:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H6pEW-0006Jh-Tj for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 09:24:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6pEW-0006JC-Iy for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 09:24:16 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1H6pEV-0006Ab-N1 for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 09:24:16 -0500 Original-Received: (qmail invoked by alias); 16 Jan 2007 14:24:14 -0000 Original-Received: from N877P001.adsl.highway.telekom.at (EHLO [62.47.53.129]) [62.47.53.129] by mail.gmx.net (mp051) with SMTP; 16 Jan 2007 15:24:14 +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: <45ACA9C6.40400@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:40357 Archived-At: >> > 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.