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: Thu, 20 Aug 2009 17:41:25 +0200 Message-ID: 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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250782988 9140 80.91.229.12 (20 Aug 2009 15:43:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2009 15:43:08 +0000 (UTC) To: martin rudalics , Emacs-Devel devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 20 17:43:02 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 1Me9n2-0006fY-Bo for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2009 17:43:01 +0200 Original-Received: from localhost ([127.0.0.1]:33857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Me9n2-00078G-05 for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2009 11:43:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Me9m1-0006JI-J1 for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:41:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Me9lv-00069a-7g for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:41:57 -0400 Original-Received: from [199.232.76.173] (port=50445 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Me9lv-00069Q-3J for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:41:51 -0400 Original-Received: from mail-yx0-f172.google.com ([209.85.210.172]:49725) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Me9lt-0004GP-Sj for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:41:50 -0400 Original-Received: by yxe2 with SMTP id 2so6778397yxe.14 for ; Thu, 20 Aug 2009 08:41:45 -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:content-type :content-transfer-encoding; bh=cgRk6p99udhBV+OjhVz9L24V6nWK/C85U1OzUZmBWiQ=; b=Jwq33DRCTA9nRfMR4d+nCoWB672lT4fldQ/yX4nocinrDBhAgyQ/eMroaRBHeuiDn8 QxmN9GoE+zWsKBXENYsu8PIfevVDmd24V3v1ICAoOxsSqQtyZXaMhB362lsRdL4geNPZ 4QZCTT4OYoTPEUMAtsdLLs0Rlh5PbCswPeKks= 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 :content-type:content-transfer-encoding; b=F4jhfcvl6y5hrhxBDkHbf3SDAsbpuUmUzBQHBBYoS/SfXm1uLaF+IswtrxtY/CNKex mHRNUN2Ag7/BfBFN6cxIp7Gx5pthh3/Wed6oOzqJirI4GhwNkY18fqrKnaWmRD162TiX NOZ2hBuVv7IelNgBUFr9ocDMr88bNPzdfgW9k= Original-Received: by 10.101.91.10 with SMTP id t10mr8880888anl.161.1250782905088; Thu, 20 Aug 2009 08:41:45 -0700 (PDT) In-Reply-To: <4A8D66D5.3000600@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:114448 Archived-At: On Thu, Aug 20, 2009 at 5:08 PM, martin rudalics wrote: >>> You should be able to use it for standard cases. =C2=A0For more complic= ated >>> cases `adjust-window-trailing-edge' will do its own resizing (and maybe >>> delete some window along the way). =C2=A0And it's the complicated cases= we >>> have to test. >> >> What I wrote is for the most complicated cases. Can you tell me more >> exactly what you think does not work? You may have seen something I >> have not seen. > > `adjust-window-trailing-edge', as a last consequence, calls size_window > with nodelete_p zero, so it's allowed to delete windows. =C2=A0I thought = you > wanted to avoid that. Thanks. I did not know adjust-window-trailing-edge could delete windows. 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? >>>>> The first thing we need for each window are some functions like >>>>> `window-parent-window', `window-prev-window', `window-next-window', >>>>> `window-vchild', `window-hchild', `window-left-column', and >>>>> `window-top-line'. =C2=A0This should be simple. >>>> They are in principle already available through window-tree. But yes, >>>> having them more explicitly would be fine. >>> Are you sure? =C2=A0Then you could write the necessary wrappers. >> >> >> Of course I am sure. I am using that in winsav.el. But I do not think >> it is a good idea to write wrappers on that level. Why do you think >> that? > > If you have the wrappers at hand, use them. =C2=A0We can write these > functions and think how to call them later. I do not have them, they are not written in that form. I meant that the information from Emacs about windows is exposed through window-tree. >>>>> Next we need `window-set-new-height' and `window-set-new-width' to se= t >>>>> and `window-new-height' and `window-new-width' to get the new values >>>>> for >>>>> a window's height and width and a function called >>>>> `window-set-new-sizes' >>>>> which copies the new values into the old values (checking whether the= y >>>> Maybe. It have to be calculated the way I have said before. Is not >>>> that clear yet? >>> But you have to _assign_ these values somehow (unless you try it with >>> `adjust-window-trailing-edge'). >> >> But I have said many times that they preferrably should be applied to >> a whole level at once. That would be much cleaner. >> >> What problems do you see with that? > > I'm just confused, that's my only problem. =C2=A0You never told me what y= ou > really want. =C2=A0What does "they preferrably should be applied to a who= le > level at once" mean? Oh, sorry, then I must have been unclear. 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. 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 I'm not yet sure how we can integrate the resizing algorithm into >>>>> `delete-window'. =C2=A0Think of a frame composed of two windows where= one is >>>>> a leaf window and the other a combined window with many subwindows. >>>>> When deleting the leaf window we have to resize the combined window >>>>> which means to run a resize algorithm which _must not fail_ to produc= e >>>>> a >>>>> perfectly valid result. =C2=A0So I'm afraid that I do have to run som= e sort >>>>> of a rudimentary resize algorithm in C first and apply our algorithm >>>>> afterwards :-( >>>> Hm. There must be something you are missing here. Why do you believe >>>> that my algorithm can't be used. This is exactly a situation where it >>>> can be used. >>> When do you call it? =C2=A0If you call it before the window gets delete= d, >>> _you_ have to delete the window (and all its subwindows). =C2=A0If you = call >>> it after the window gets deleted but before the others are resized, the >>> Elisp call occurs in an invalid window configuration. =C2=A0How would y= ou >>> handle that? >> >> >> The elisp code I wrote does not in any way care if the configuration >> is valid or not. It just looks at the available size and the >> restrictions. Is not that clear? What problem do you see with that? > > I can't call Elisp code in an invalid configuration. =C2=A0Suppose your > algorithm decides that it cannot resize. =C2=A0What shall the display eng= ine > display then? =C2=A0The invalid configuration? I am trying to understand what you mean here. You can call my routines before deletion. It does not depend on the actuall configuration, just the fictive configuration you tell about. >>>>> As far as frame-resizing and the necessary deletion of windows is >>>>> concerned I think we should really run our algorithm and, if it fails= , >>>>> simply delete the least recently used window until it doesn't fail an= y >>>>> more (in the worst case this will resize a fixed-size window). >>>> So you still think we should delete windows? I do not. >>> If someone eventually comes up with a solution that handles frame >>> resizing (and minibuffer resizing!) I'll be the first to go for it. >> >> I have suggested one. You have not replied to it. > > No one ever has suggested a practicable solution. =C2=A0AFAICT you propos= ed > to ask the user what to do in that case. =C2=A0That's not practicable IMO= . 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. 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".) >>>> Did not Stefan say he want to avoid it too? >>> He did not provide a solution for it - and I suppose he's smart enough >>> not to propose one. >> >> You are misunderstanding him. He wants ideas. Of course he knows about >> the difficulties. > > Stefan earlier said in this thread to > > - either somehow make it possible to undelete windows (I'd *much* rather > =C2=A0not, but maybe if we make it sufficiently restrictive it'd be OK). > - or maybe avoid deleting the window in this case, instead leave it > =C2=A0a size-0, and delete it at some later time (when would that be?). > - prevent frame resizing that would require deleting a window. > > and that's where we still are more or less. =C2=A0Everything I heard from > people since that was not told from an implementor's POV. Hm. I answered to that that I think it is better to use a single alternate window like above. That is very much an implementors POV. Why don't you think it is? (I believe maybe you think so because I do not adhere to the old routines, but I am not sure.) I did not go into details, but: - undeleting seems terribly confusing from a users point of view. - size-0 windows in a case like this would be the same. - we probably can't prevetn resizing with all window managers. >>>> Did you seriously try to understand my suggestion for how to handle it= ? >>> Did you have a serious suggestion? >> >> Yes. >> >> Martin, can I take this to the list again. I thought we would save >> time this way, but I am starting to doubt it. Can I send this mail to >> the list? > > Sure, go ahead ;-) Ok, done. It took it off list since I thought we should discuss boring details, but the got back to principal discussion again so here we are on the list again! > martin >