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: Tue, 16 Jan 2007 11:32:38 +0100 Message-ID: <45ACA9C6.40400@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> <45ABC474.3010208@gmail.com> <45ABD474.9040206@gmx.at> <45ABE387.9010306@gmail.com> <45AC03E2.5080109@gmx.at> <45AC18F4.4@gmail.com> <45AC82D1.1050609@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 1168943586 27076 80.91.229.12 (16 Jan 2007 10:33:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 Jan 2007 10:33:06 +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 11:33:02 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 1H6lca-0002UN-B4 for geh-help-gnu-emacs@m.gmane.org; Tue, 16 Jan 2007 11:32:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6lca-0007zS-9i for geh-help-gnu-emacs@m.gmane.org; Tue, 16 Jan 2007 05:32:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H6lcM-0007z1-Da for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 05:32:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H6lcK-0007yd-IH for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 05:32:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6lcK-0007yT-EA for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 05:32:36 -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 1H6lcJ-00054o-Ny for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 05:32:36 -0500 Original-Received: from c83-254-145-24.bredband.comhem.se ([83.254.145.24]:60125 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1H6lcH-0005p1-4w; Tue, 16 Jan 2007 11:32:34 +0100 User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) Original-To: martin rudalics In-Reply-To: <45AC82D1.1050609@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 1H6lcH-0005p1-4w. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1H6lcH-0005p1-4w 4861334f96a45cf3a38399793f0fde3e 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:40354 Archived-At: martin rudalics wrote: Hi Martin, thanks for answering so that we can clear this out. But I still think we are misunderstanding each other a little bit. Please see if my answers below. > > 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. > > 2) I must check all overlays in these buffers > > Yes (unfortunately) but _only_ in the buffers mentioned above. > > > 3) The only thing I have to check in the overlays is the 'window prop > > Yes. > > > 4) I only have to care if the prop value is a window in the saved tree > > Yes. > > > 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.) > > 6) Otherwise I make a new overlay -- seldom > > _Never_ make a new overlay. Yes, never in the normal use case. > > The above is what I am doing. Is any of those points incorrect in your > > opinion? Here is the code: > > > > (dolist (buf (buffer-list)) > > `buffer-list' is bad. I'd use something like > > (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? > If the old window is still alive don't do anything. Windows that > survived the reconfiguration should not be on `win-list'. In the normal use case what you are saying is correct, but there may be other cases. > > I believe it would be possible to right code to manipulate the internal > > tree as above. A solution building on that would probably use the > > resizing part from my elisp solution (or something similar). > > The only time and space consuming operation is finding the overlays and > changing their property. There's nothing you can do about that. Note > that current solutions (like `edebug-current-windows') ignore overlays > (and many other things like dedicated windows) completely. This could > be corrected with your algorithm, provided the save/restore step occurs > smoothly. If so that would be good of course. > For `desktop-save', on the other hand, you should think of an option to > ignore overlays, though. Storing overlays on disk is hardly conceivable > as long as we don't even bother to save text properties. Yes, thanks, I have thought of that and just asked the maintainer of desktop.el if he is interested.