From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Sat, 22 Aug 2009 13:00:44 +0200 Message-ID: <4A8FCFDC.2030608@gmx.at> References: <4A8D12B3.6070502@gmx.at> <4A8D46C9.1010108@gmx.at> <4A8D66D5.3000600@gmx.at> <4A8D92AC.5010404@gmx.at> <4A8E95A3.5040604@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250938876 22373 80.91.229.12 (22 Aug 2009 11:01:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Aug 2009 11:01:16 +0000 (UTC) Cc: Emacs-Devel devel To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 22 13:01:07 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MeoLK-0005ja-8V for ged-emacs-devel@m.gmane.org; Sat, 22 Aug 2009 13:01:06 +0200 Original-Received: from localhost ([127.0.0.1]:44757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeoLJ-0001r9-NP for ged-emacs-devel@m.gmane.org; Sat, 22 Aug 2009 07:01:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeoLC-0001on-BP for emacs-devel@gnu.org; Sat, 22 Aug 2009 07:00:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeoL6-0001gG-CP for emacs-devel@gnu.org; Sat, 22 Aug 2009 07:00:56 -0400 Original-Received: from [199.232.76.173] (port=54763 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeoL6-0001g2-8z for emacs-devel@gnu.org; Sat, 22 Aug 2009 07:00:52 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:60628) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MeoL5-0006EJ-Ds for emacs-devel@gnu.org; Sat, 22 Aug 2009 07:00:51 -0400 Original-Received: (qmail invoked by alias); 22 Aug 2009 11:00:48 -0000 Original-Received: from 62-47-45-144.adsl.highway.telekom.at (EHLO [62.47.45.144]) [62.47.45.144] by mail.gmx.net (mp007) with SMTP; 22 Aug 2009 13:00:48 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+6lx59P6G6e0SYn5oONVG6OVln7BvEGJINmnb/S+ 1nnzrx0C3/kKHk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114512 Archived-At: > There are some ideas here that are rather similar but differs a bit. > You and Stefan have been talking about the idea about treating the > size changes as transactions with possible roll back. > > That seems ok to me. But I choosed a little bit different route. I am > trying to make the calculations first and only apply them if new sizes > fit. That's fine. But it won't harm to check twice whether the sizes really fit. > However with my idea there is still the problem of applying the > new sizes without bumping into any restriction during the applying > phase. This could happen even if you know that the final result will > fit. > > That was the reason I asked for a function above to set the sizes of > all children at once. But such a function will not help since bumbing > into restrictions can happen further down the tree also. > > So what I need is still a way to apply the new sizes without > restriction checks during that phase. Am I clear enough when I try to > explain this? How should I do to avoid the restrictions in this phase? What problems do you have doing your calculations using copies of the original sizes? We can initialize these with the current values and retrieve via `window-new-height' and `window-new-width'. > Yes, I know that this is lacking. I have been wondering about this > part. It is not clear to me how resizing and deletion/creation of > windows are tighed together in the current code. I think those parts > should be broken up. It's not entirely trivial to do that. Resizing during window deletion must succeed, at least in a second attempt. So if we want to do this in Elisp we must be able to resize fixed-size windows and never issue a failure. > Can you please try to explain how things are now > and if you see some way to brake those things apart? I explained that in another post: - `delete_window' resizes either the sibling above or below W and is not allowed to delete other windows. So inherently `delete_window' is not able to handle fixed-size windows correctly even if size_window were. To handle fixed-size windows "more" correctly `delete_window' should be able to operate on all windows. Obviously, in a two-window case with the only other window fixed-size we have to resize that other window. > Then I assume that window configurations must be used to get my > suggestion to work. The drawback I see then is that window pointers > migh gets lost. Are there any way around that? Which window pointers get lost? > I am sorry, but I can't see why that should make it harder to > understand. The text to show can of course be changed to avoid some > confusion. Does not that help? Like "you can restore the previous configuration within a suitable frame-size" by hitting ... Maybe. Let's add it to the set of possible solutions. >>>> You do undelete all the time. It's completely transparent. >>> How can it be transparent if windows disappears and reappears? I must >>> be misunderstanding you somehow... >> There might be no redisplay in between. > > How can you avoid that when the frame gets too small? `adjust-window-trailing-edge' can temporarily delete a window and resurrect it without the user noticing because there's no redisplay in between. When you program in Elisp you can try to inhibit redisplay but I would not recommend that. In any case, I don't understand how this should relate to frames getting to small. >> In many applications (Thunderbird is one of them) I can make subwindows >> disappear completely by dragging one of their borders and make them >> reappear later by dragging on the border where they disappeared. > > Are there no sign at all that there are 0-size windows there? Thunderbird leaves a horizontal divider behind. martin