From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Fri, 21 Aug 2009 01:08:56 +0200 Message-ID: References: <4A882312.6020106@gmx.at> <4A8D12B3.6070502@gmx.at> <4A8D46C9.1010108@gmx.at> <4A8D66D5.3000600@gmx.at> <4A8D92AC.5010404@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250809784 30109 80.91.229.12 (20 Aug 2009 23:09:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2009 23:09:44 +0000 (UTC) Cc: Emacs-Devel devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 21 01:09:37 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 1MeGlF-0007LU-99 for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 01:09:37 +0200 Original-Received: from localhost ([127.0.0.1]:59809 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeGlE-0005nJ-Jl for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2009 19:09:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeGl0-0005bo-Hx for emacs-devel@gnu.org; Thu, 20 Aug 2009 19:09:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeGkv-0005WW-Id for emacs-devel@gnu.org; Thu, 20 Aug 2009 19:09:22 -0400 Original-Received: from [199.232.76.173] (port=44547 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeGkv-0005WN-A6 for emacs-devel@gnu.org; Thu, 20 Aug 2009 19:09:17 -0400 Original-Received: from mail-yw0-f190.google.com ([209.85.211.190]:37796) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MeGku-0001ww-RI for emacs-devel@gnu.org; Thu, 20 Aug 2009 19:09:17 -0400 Original-Received: by ywh28 with SMTP id 28so391595ywh.27 for ; Thu, 20 Aug 2009 16:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=KN/qpC6Me/nsynKwi+VfBa60DHeZMSmx7V6JaPHNgRM=; b=RgIBNLA56WLYynDcX2I08v+8txnNLOo3lrCQdWhxJuLmI0QVcsIPK9t9/TkSp8CO7p gfjtMtMdOEoPrSsv3I0XaqqszrapfdAzSbeXsFpezTEkgOfyA8sj4E0v6VpmcGOuJURI x28gdqUUJ3wL7cUvdaISByzi6/Sj7i+mHyrpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=TaipvzlzFw3dM/tRmAwQKi3xDZAjqY5Zs5eXdSfOc1bEWVK2QeKLJrEZpPfh+IJwrn StMzYICoXMM3LR5aA1Wfm6Y2nVtrUpnZ3cqmJmrkXtAJRViXKzYhVLQNm/veDL24RQnQ EKqAwGxmCu/3DibJbSFNUbsELvRD7l0Yss5QE= Original-Received: by 10.100.53.9 with SMTP id b9mr526094ana.33.1250809756198; Thu, 20 Aug 2009 16:09:16 -0700 (PDT) In-Reply-To: <4A8D92AC.5010404@gmx.at> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:114466 Archived-At: On Thu, Aug 20, 2009 at 8:15 PM, martin rudalics wrote: > Every resize operation may delete windows. =C2=A0But some like the minibu= ffer > resize operations and `adjust-window-trailing-edge' save the > window-configuration around resize calls to avoid that windows get > deleted. =C2=A0I'm not sure whether that's of any help for you, though. Thanks. I had no idea about that. I will think about it. >> 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. All children to a window are on the same level. >> 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. Do I understand you right, do you say: These should set the size without any checking. >>> I can't call Elisp code in an invalid configuration. =C2=A0Suppose your >>> algorithm decides that it cannot resize. =C2=A0What shall the display e= ngine >>> display then? =C2=A0The 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. =C2=A0I need a resize function that's executed _as part o= f_ > 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"? =C2=A0You want all thos= e > links to the next, previous, parent windows be valid, I suppose. You can make a lisp copy of the configuration. This copy should contain just the info needed to compute the new sizes. If you want the sizes after deletion then just do not include the window you want to delete in the copy. >> 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. =C2=A0I don't ge= t at > what you mean by "pointer swapping". =C2=A0If such pointer swapping were = as > easy as you believe, we could have used that all the time instead of > saving window-configurations. I thought a window-configuration was a copy with the information necessary to recreate the window configuration. That is a totally different thing and can't be done the way I suggest. I am not sure that what I suggest is that very easy to do. I thought you should comment on it, but we are miscommunicating for some reason. I have not looked at the implementation, but I know you have so I am asking you. (I have rephrased and clarified my question below.) I guessed there must be some pointer (in a general sense) for each frame to the root window. I do not know the actual implementation, but I just glanced at it. Unfortunately it takes some time for me to read C so I guess a little. I can see there is a Lisp_Object called root_window in struct frame. This is the pointer I am talking about. My question (and suggestion) to you is this: Would it be possible to temporarily replace the frames root_window with a new window when the frame size gets so small that the window configuration does not fit? Whether this is easy (or perhaps even possible) is of course dependent on the details in this implementation. It depends on for example on how drawing of windows are done. Is drawing of a frame something that starts from the frame and then goes down to look at the windows? Or does the windows live a life on their on in this regard? I have assumed the former when I suggested to just swap the roor_window pointer. You know more about the implementation details and can probably give a better answer. Maybe I should have explained this from the beginning, but I believed you should answer something like the above to my suggestion. I am sorry for beeing too short. >> 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? I thinks I have seen such cases, yes. (But I do not remember where now.) You seem to suggest that it would be hard to understand for the user. In that case, why? >> - undeleting seems terribly confusing from a users point of view. > > You do undelete all the time. =C2=A0It's completely transparent. How can it be transparent if windows disappears and reappears? I must be misunderstanding you somehow... >> - size-0 windows in a case like this would be the same. > > Many applications do that. Can you explain how you mean? >> - we probably can't prevetn resizing with all window managers. > > martin >