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: window groups Date: Sun, 01 Jun 2008 00:37:59 +0200 Message-ID: <4841D347.3030908@gmx.at> References: <483D4E9A.9020001@gmx.at> <87wsldgkgz.fsf@stupidchicken.com> <87abi9j57j.fsf@catnip.gol.com> <87ve0wbxhb.fsf@stupidchicken.com> <874p8gkafs.fsf@catnip.gol.com> <483F4216.9060606@emf.net> <483FA7C6.7060408@gmx.at> <48402E69.4000003@emf.net> <48411600.3000309@gmx.at> <4841545B.50004@gmx.at> <4841893F.6040402@emf.net> 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 1212274775 14845 80.91.229.12 (31 May 2008 22:59:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 May 2008 22:59:35 +0000 (UTC) Cc: Juanma Barranquero , Chong Yidong , emacs-devel , Miles Bader To: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 01 01:00:16 2008 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 1K2a3b-0007Ec-M7 for ged-emacs-devel@m.gmane.org; Sun, 01 Jun 2008 01:00:16 +0200 Original-Received: from localhost ([127.0.0.1]:58902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K2a2p-0003xh-Oz for ged-emacs-devel@m.gmane.org; Sat, 31 May 2008 18:59:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K2a21-0003Ot-Fe for emacs-devel@gnu.org; Sat, 31 May 2008 18:58:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K2a1z-0003Oh-Rc for emacs-devel@gnu.org; Sat, 31 May 2008 18:58:36 -0400 Original-Received: from [199.232.76.173] (port=59576 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K2a1z-0003Ob-L0 for emacs-devel@gnu.org; Sat, 31 May 2008 18:58:35 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:33111) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1K2a1z-0002os-14 for emacs-devel@gnu.org; Sat, 31 May 2008 18:58:35 -0400 Original-Received: (qmail invoked by alias); 31 May 2008 22:58:31 -0000 Original-Received: from 62-47-48-160.adsl.highway.telekom.at (EHLO [62.47.48.160]) [62.47.48.160] by mail.gmx.net (mp051) with SMTP; 01 Jun 2008 00:58:31 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX199p61KItR9G0CqYTJuLZP1kaQ9BR2gG04269BRH9 Z/kLtRCTGddUQg User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <4841893F.6040402@emf.net> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:98154 Archived-At: > When a temporary window or a pop-up created by splitting the root > of a frame is deleted *and* the user hasn't otherwise touched the > window configuration, *then* precise sizes should be restored. > So, if a user resizes a frame or explicitly resizes, deletes, or splits > a window it doesn't matter as much. But if none of those things have > happened since the pop-up, the precise sizes should be restored. Yes. `set-window-configuration' frequently restores a configuration without users noticing. > Currently, if you delete one of the windows in (say) a horizontal > stack, then by default the new space is allocated proportionally among > the remaining windows. When you delete a window its space is only given to the window above or on the left (if no such window exists it's given to the window below or on the right). I once thought about changing that behavior in the way you describe it but realized that it wouldn't make sense for temporary windows you want to get rid off soon. > That won't always DTRT in the case of > pop-ups that split the root of the frame. For example, before the > pop-up, a stack of windows may have each had an exactly equal > number of lines. When the pop-up appears, the remaining lines > might not divide evenly among the other windows in the stack - > so they are no longer all the same size. When the pop-up disappears, > Emacs won't always restore them to be all the same size. What you describe here is what happens when you delete a window and the window above/on the left (below/on the right) is an internal window. In that case subwindows are resized proportionally. Small windows that are not fixed-size may get larger than they were before creating the window you delete. > That's the case I was talking about fixing and I was talking about > fixing it only in a very narrow case: that the user hasn't done anything > to change the window configuration other than triggering the pop-up > window and then dismissing the pop-up window. But that's the typical use case of `save-window-excursion'. Or am I missing something? > For various reasons I found the original description really difficult > to understand and believe in. Other people have already pointed out > some ways in which it "isn't lispy". I would add that it is pretty > complicated but only a weak rationale is given for the complexity. > It's complicated because it adds 3 parameters (that seem hard to > explain) to split-window. The SAFE argument is something I need to get rid of these strange window-min-height|width bindings you find in Elisp code. These bindings are misleading because people sometimes believe that they will prevent the emanating windows from being deleted later on. While the SAFE parameter comes handy for resizing window groups these can happily live without it. The INVERT argument is used for creating the new window on the "other side" of the original window. I could merge it into the HORIZONTAL parameter by providing two new values 'left and 'above in addition to nil and t and we are left with one argument I have to add. One additional argument would be needed anyway if you want to split the frame root window instead of a visible one. > It's complicated because it adds a new > primitive concept (window groups) and that concept comes with > non-intuitive restrictions (like the non-nesting of groups and the > non-existence of single-window groups). Rather, these restrictions simplify both semantics and implementation. Try to write down the semantics of nested groups in a few sentences. The single-window restriction can be removed (though talking about a window group when there's only one window doesn't strike me as overly intuitive). > I take your word for it that, given those new features, you can implement > something that looks a lot like certain other IDEs. On the other hand, > these features don't obviously have many other uses besides that - they > aren't very "general," at least as far as I can tell from the description. Well I use them all the time and I never use IDEs. > Presumably you want to use the new features you're working on and then > build higher-level application code to actually implement IDE features. > Let's just assume that all of your higher level code (actual or planned) is > just fine but ask: is there a simpler, more general substitute for the > low-level > changes? I don't intend to implement any IDE features. But I think that if and when such features were integrated into Emacs it should be done in a sane and safe way. > Well, how about this? Modify split-window with just one new additional > parameter which, if that parameter is 'root, then a top-level split is > implied. > If that parameter is nil, current behavior is implied. No other values > for > that parameter should be defined yet. > > I *suspect* (and its only a suspicion) that those alone are sufficient to > accomplish everything you are trying to do with window groups, without > even very much pain (and, perhaps with some added flexibility). Modifying `split-window' to do what I described was straightforward. The only twist was writing a subroutine to shift edges of subwindows appropriately - something you have to do anyway when you split the frame root window. The more complicated part was cloning a configuration previously saved by `current-window-configuration'. People asked for such a thing although I personally don't use it. > Not to confuse things too much but let me also suggest how, in the future, > the new split-window parameter that might be 'root could take on other > values. Every window is conceptually part of both a horizontal and I suppose you mean "either" here not "both". > vertical stack of windows, containing 1 or more windows. One possibility > is that if the new split-window parameter is a window, then the pop-up > splits off the entire horizontal or vertical stack of which that window is > a part. This is a sneaky way to "expose the window tree to lisp" as > Mile's > puts it. (Additional sneakiness would be a function that, given a window, > returns an ordered list of all windows in the same horizontal or vertical > stack.) Would be very easy to implement but hardly useful. People don't think in terms of "stacks of windows". That's why I propose groups as some sort of abstraction. > That would have use in IDE-style interfaces. For example, suppose that > down the screen on the left are a series of narrow "navigation" windows > and on the right there is an edit area, an interaction area, and a debugger > area. A "help window pop-up" could usefully be constrained to take > up space just on the right of the screen. That would be a natural > generalization > of using 'root and having it take up space on the whole screen. If your edit area were split horizontally you'd be stuck. My proposal defines the edit area as a group and you will get your "help window" below (or above) that group.