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 08:46:25 +0100 Message-ID: <45AC82D1.1050609@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> 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 1168933710 26871 80.91.229.12 (16 Jan 2007 07:48:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 Jan 2007 07:48:30 +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 08:48:27 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 1H6j3H-0003A3-Pt for geh-help-gnu-emacs@m.gmane.org; Tue, 16 Jan 2007 08:48:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6j3H-0002DJ-Or for geh-help-gnu-emacs@m.gmane.org; Tue, 16 Jan 2007 02:48:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H6j30-00029l-PG for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 02:47:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H6j2z-000273-49 for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 02:47:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6j2z-00026s-0u for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 02:47:57 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1H6j2y-0007n6-Ag for help-gnu-emacs@gnu.org; Tue, 16 Jan 2007 02:47:56 -0500 Original-Received: (qmail invoked by alias); 16 Jan 2007 07:47:55 -0000 Original-Received: from N810P001.adsl.highway.telekom.at (EHLO [62.47.45.33]) [62.47.45.33] by mail.gmx.net (mp024) with SMTP; 16 Jan 2007 08:47:55 +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: <45AC18F4.4@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:40352 Archived-At: > 1) I think I must search all buffers No. Only the buffers that have an ovlwin-window association. > 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. > 6) Otherwise I make a new overlay -- seldom _Never_ make a new overlay. > 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)))))) ... > (with-current-buffer buf > (save-restriction > (widen) > (dolist (overlay (overlays-in (point-min) (point-max))) > (when (setq ovlwin (car (memq (overlay-get overlay 'window) > oldwins))) > (setq window (cadr (assoc ovlwin win-list))) > ;; If the old window is still alive then copy overlay, > ;; otherwise change the 'window prop. This should be something along the (100% incorrect) (dolist (overlay (overlays-in (point-min) (point-max))) (when (setq window (cadr (assoc (overlay-get overlay 'window)) win-list)) (overlay-put overlay 'window window))) If the old window is still alive don't do anything. Windows that survived the reconfiguration should not be on `win-list'. > (if (not (and (window-live-p ovlwin) > (window-frame ovlwin))) > .... > > `oldwins' is a list with the old windows, ie the windows in the saved tree. > 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. 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.