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: Thu, 20 Aug 2009 20:15:08 +0200 Message-ID: <4A8D92AC.5010404@gmx.at> References: <4A87F8B8.6050102@gmx.at> <4A882312.6020106@gmx.at> <4A8D12B3.6070502@gmx.at> <4A8D46C9.1010108@gmx.at> <4A8D66D5.3000600@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 1250793471 11706 80.91.229.12 (20 Aug 2009 18:37:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2009 18:37:51 +0000 (UTC) Cc: Emacs-Devel devel To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 20 20:37:44 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 1MeCW7-0003mB-N2 for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2009 20:37:44 +0200 Original-Received: from localhost ([127.0.0.1]:34428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeCW6-0005MR-T3 for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2009 14:37:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeCAR-00055M-LV for emacs-devel@gnu.org; Thu, 20 Aug 2009 14:15:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeCAN-00052U-Ni for emacs-devel@gnu.org; Thu, 20 Aug 2009 14:15:19 -0400 Original-Received: from [199.232.76.173] (port=55053 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeCAN-00052D-EB for emacs-devel@gnu.org; Thu, 20 Aug 2009 14:15:15 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:58707) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MeCAM-0003aW-SJ for emacs-devel@gnu.org; Thu, 20 Aug 2009 14:15:15 -0400 Original-Received: (qmail invoked by alias); 20 Aug 2009 18:15:12 -0000 Original-Received: from 62-47-53-48.adsl.highway.telekom.at (EHLO [62.47.53.48]) [62.47.53.48] by mail.gmx.net (mp043) with SMTP; 20 Aug 2009 20:15:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/GLJZRTx7G9Dd8qX+Ay4W4ho5/KqRmOLKexcOg7h IEDu6uTcLtmNO+ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 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:114451 Archived-At: > Thanks. I did not know adjust-window-trailing-edge could delete > windows. It resurrects them via `set-window-configuration'. But size_window can delete them temporarily. Most of this discussion was triggered by Stefan's being unhappy with that. > The doc string does not tell about that. I thought it was > correct. Could you please try to get the doc string corrected to > reflect the functions current state? Every resize operation may delete windows. But some like the minibuffer resize operations and `adjust-window-trailing-edge' save the window-configuration around resize calls to avoid that windows get deleted. I'm not sure whether that's of any help for you, though. > The algorithm computes level by level in the second pass (ie on its > way down) how the windows should be sized. So you have the sizes for > all windows on that level at once. I still don't understand what a "level" is. > You can of course use > adjust-window-trailing-edge (setting restcrictions temporary to be > able to do that), but it seems much easier to be able to set them all > at once. The routines we have now for setting window sizes does > checking that has already been done by my functions then. But that's what the functions `set-new-window-height' and `set-new-window-width' I proposed earlier should do. >> I can't call Elisp code in an invalid configuration. Suppose your >> algorithm decides that it cannot resize. What shall the display engine >> display then? The invalid configuration? > > I am trying to understand what you mean here. You can call my routines > before deletion. I can't because at that time the window still exists and you don't delete windows. I need a resize function that's executed _as part of_ the Emacs command `delete-window'. > It does not depend on the actuall configuration, just > the fictive configuration you tell about. How do I tell it about a "fictive configuration"? You want all those links to the next, previous, parent windows be valid, I suppose. > Not really. I suggested: > > - showing an alternate single window with information that the windows > does not fit > - and also keep the other configuration so you can put it back when > the window gets large enough again. > - this should be kept by just swapping a pointer between that single > window with information and the "real" configuration. The canonical way to handle this is keeping "the other configuration" in a window-configuration, something Stefan wants to avoid. I don't get at what you mean by "pointer swapping". If such pointer swapping were as easy as you believe, we could have used that all the time instead of saving window-configurations. > What do you find not practical about this? (The alternate single > window should just say something like "your windows does not fit, > please make the frame larger".) Do you know any application proposing to enlarge its window? > - undeleting seems terribly confusing from a users point of view. You do undelete all the time. It's completely transparent. > - size-0 windows in a case like this would be the same. Many applications do that. But they don't have a built-in tiling window manager like Emacs. > - we probably can't prevetn resizing with all window managers. martin