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: Sun, 01 Jun 2008 20:49:44 -0700 Message-ID: <48436DD8.4060107@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> <4841893F.6040402@emf.net> <4841D347.3030908@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 1212375940 24691 80.91.229.12 (2 Jun 2008 03:05:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Jun 2008 03:05:40 +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 Mon Jun 02 05:06:21 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 1K30N7-0005I4-MS for ged-emacs-devel@m.gmane.org; Mon, 02 Jun 2008 05:06:10 +0200 Original-Received: from localhost ([127.0.0.1]:35689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K30ML-00077R-Mi for ged-emacs-devel@m.gmane.org; Sun, 01 Jun 2008 23:05:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K30MG-00077D-Vd for emacs-devel@gnu.org; Sun, 01 Jun 2008 23:05:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K30MG-00076v-64 for emacs-devel@gnu.org; Sun, 01 Jun 2008 23:05:16 -0400 Original-Received: from [199.232.76.173] (port=48814 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K30MF-00076s-V2 for emacs-devel@gnu.org; Sun, 01 Jun 2008 23:05:16 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:35357) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1K30MA-0001cB-RX; Sun, 01 Jun 2008 23:05:11 -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 32009796; Sun, 01 Jun 2008 20:05:03 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <4841D347.3030908@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:98210 Archived-At: martin rudalics wrote: > > 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? About "missing something" on more than just this qusetion -- er, yes. No blame, unless to me. I'm a stranger here, more or less. And I'm only just starting to return to paying attention to Emacs internals. I gather I'm not explaining myself with contextually effective clarity. Oh well. I won't dwell on it. About "save-window-excursion" -- yes, you're missing something there, too. When a help window pops up (say, for describe-function) it persists outside of any save-window-excursion. I am proposing that, using window properties and various hooks, a user should be able to delete that window and restore the previous window configuration of the same frame provided that the user has not otherwise modified the window configuration. I'm implying a one-level-undo, of sorts and in limited cases, for the window configuration of a frame. Data for such an "undo" could be saved as window properties and tended by hook functions. > > > 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. It sounds like you are addressing confusion by adding confusingness. In your original description, what does "safe defaults" mean? > > 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. I see. My own counter-proposal fails to address that very need. So I can agree something like that is desirable. > > One additional argument would be needed anyway if you want to split the > frame root window instead of a visible one. Well, I proposed *one*. And you've got me convinced on a boolean parameter for INVERT. (I do appreciate your patience here. I hope the worst case is that I'm helping you simply explicate your proposal. I still think it is too complicated and these new agreements we've found are only a small fraction of that complexity. Again, consider the power of window properties + hooks for most of what you want to do. Right now we're only agreeing on some API for editing the window tree but not agreeing on anything close to "groups". And, please: I do mean to exude humility here. I was pretty darn deep into Emacs internals a few years back and pretty darn deep into Emacs applications and, for that matter, rather deep into working on a rewrite before rudely interrupted. I don't pretend to be fully up to speed on the current mindset of the main developers and state of the code -- just trying to get back closer to that state.) > > > 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'm just not sure "groups" are needed at all. If something like groups are needed, then one would want a nestable version. They probably aren't needed. I think you're adding a new abstraction where none is needed. That the semantics of nested groups may not have a reasonable solution is a hint that groups may not be needed at all. Emacs doesn't need to be able to precisely emulate Eclipse, especially if in a simpler and more extensible way it can create a close substitute. Emacs may well come out *better*. > > > 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. If you'll indulge me -- and again, who am *I* to ask -- could you explain a bit? I made that claim that these are obscure and not general and you're making the opposite claim. Yours is easier to prove. What examples should I look at, please? > 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. > We agree about "safe and sane" -- the only question is what exactly that means :-) > > 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. Lots of things that are "straightforward" can come back and bite you in the rear end down the line. That's the main problem. There's an embarrassing over-supply of the "straightforward change" but, experience shows, only a tiny fraction of those changes are comfortable in the long run -- the others become "legacy" (some examples of which you are wrestling with -- so don't make more if you can avoid it). > > 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. Some of the GUI apps that I use, unrelated to Emacs, make use of a similar feature and I find it to be one of the things I like about those apps. I don't know that I would tie that cloning to Emacs' current concept of window-configuration, though. > > > 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". I mean "both" in this way: Each window is part of a horizontal stack of H members and a vertical stack of V members subject to the invariant that: (H >= 1 and V == 1) or (H == 1 and V >= 1) > > > 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. I don't know (and I don't think you do, either) what "people think" in some free-floating general way. The "model" -- the mathematical abstraction -- of a window config is a tree and there's just a few ways to characterize it. What I tend to believe is that the more lucidly APIs and UIs can present the actual model, the more clearly people will think and do useful things with it. Are you familiar with XDM as in DOM or XPATH? To "present the window tree" in APIs more than is already done we need a similar approach -- a way to assign "addresses" to the tree in ways that correspond to how algorithms navigate the tree. This would be a lot easier to talk about at higher bandwidth with a whiteboard at hand :-) > > > 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. > Excuse my brain-fart there and swap "horizontal" and "vertical" in what I said and it should make perfect sense. -t