From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: window groups Date: Sat, 31 May 2008 10:22:07 -0700 Message-ID: <4841893F.6040402@emf.net> 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> 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 1212251953 19957 80.91.229.12 (31 May 2008 16:39:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 May 2008 16:39:13 +0000 (UTC) Cc: Juanma Barranquero , Chong Yidong , emacs-devel , Miles Bader To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 31 18:39:54 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 1K2U7R-0000rU-1C for ged-emacs-devel@m.gmane.org; Sat, 31 May 2008 18:39:49 +0200 Original-Received: from localhost ([127.0.0.1]:56062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K2U6f-00022J-6V for ged-emacs-devel@m.gmane.org; Sat, 31 May 2008 12:39:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K2U5Z-0001Iw-Q8 for emacs-devel@gnu.org; Sat, 31 May 2008 12:37:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K2U5X-0001Gg-Lk for emacs-devel@gnu.org; Sat, 31 May 2008 12:37:53 -0400 Original-Received: from [199.232.76.173] (port=44879 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K2U5X-0001GV-HD for emacs-devel@gnu.org; Sat, 31 May 2008 12:37:51 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:54072) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1K2U5S-0003xK-Fc; Sat, 31 May 2008 12:37:46 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.114.9] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 31930785; Sat, 31 May 2008 09:37:32 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <4841545B.50004@gmx.at> 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:98145 Archived-At: martin rudalics wrote: > > Where is "here"? Your local changes? Because that's at least three > > more args than the standard split-window accepts. > > My local changes. Have a look at the description that started this > thread. > Aha! That's why I couldn't find it. I have a suggestion about the description that started this thread but, first, to clear up a misunderstanding: In the other message you answered one of my questions: >>> Returning "precisely" to former sizes is non-trivial. >> How so? > Because your context might have changed in between. For example, when > leaving a `save-window-excursion' you don't want your frame get resized. Context got lost in the quoting there and caused confusion. 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. That would *almost* happens automatically but not quite. 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. 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. 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. So, back to the original description: 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. 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). 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. Here is the thing, though: 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? Stefan tells me that "window properties" are being added at this time. Emacs already has a lot of handy "hooks" to catch significant events as, for example, the window-configuration-change-hook 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). No? 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 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.) 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. -t