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: Mon, 02 Jun 2008 14:32:27 -0700 Message-ID: <484466EB.70808@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> <48436DD8.4060107@emf.net> <4843BEB1.9020900@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 1212439706 7891 80.91.229.12 (2 Jun 2008 20:48:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Jun 2008 20:48:26 +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 22:49:07 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 1K3Gxj-000364-Oj for ged-emacs-devel@m.gmane.org; Mon, 02 Jun 2008 22:49:04 +0200 Original-Received: from localhost ([127.0.0.1]:36387 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K3Gwx-0007ry-Dg for ged-emacs-devel@m.gmane.org; Mon, 02 Jun 2008 16:48:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K3Gws-0007nK-6G for emacs-devel@gnu.org; Mon, 02 Jun 2008 16:48:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K3Gwr-0007lP-4U for emacs-devel@gnu.org; Mon, 02 Jun 2008 16:48:09 -0400 Original-Received: from [199.232.76.173] (port=40864 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K3Gwq-0007l5-V8 for emacs-devel@gnu.org; Mon, 02 Jun 2008 16:48:09 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:56184) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1K3Gwl-0001re-Ch; Mon, 02 Jun 2008 16:48:04 -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 32073663; Mon, 02 Jun 2008 13:47:45 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <4843BEB1.9020900@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:98259 Archived-At: martin rudalics wrote: > > 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. > > By design. Incidentally, I hate those save-window-excursions throwing > me back to some unwanted state of affairs I forgot about long ago ... I hate that too. And, yes, help windows work that way by design. All I'm saying is that you have interaction that goes: 1. User does something that causes.... 2. Help window to pop up.... 3. User does stuff but nothing effecting window config... 4. Use deletes the help window then the resulting window config should be as at step 0. (Well, that and as we agree there should be *some* mechanism to pop-up other than by splitting a leaf window.) > > > 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. > > `View-quit' should do that. If it doesn't, please complain. I spent > some time on making it DTRT. Uh... where is that? I've been doing this blind, just on general principles. I was thinking I'd probably build the latest 23.x snapshot this week sometime. > > > 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. > > A one-level-undo is equivalent to saving `current-window-configuration' > followed by `set-window-configuration' to the saved value. It works > reliably provided the frame still exists but is used a bit too often for > my taste. IIRC ECB has a complete undo-history for window configuration > changes. A complete undo history or, hey, how about a ring of saved configs, could be nice. Only experience with failed experiments in that area, imo, can arrive at a nice UI. > > > It sounds like you are addressing confusion by adding confusingness. > > In your original description, what does "safe defaults" mean? > > "safe defaults" are values that don't crash Emacs. For some reasons, > the display engine is not able to digest windows smaller than a certain > size. In general, I use "safe" for "anything that's not bad" and > consider crashing Emacs "bad" in this context. (On the other hand, a > person who wrote a program to crash Emcas would consider her program > "safe" iff it were able to crash Emacs by noon say.) Uh.. I guess I'll just say "hrrmmm" and suggest some fresh air. > > > Again, consider the power of window > > properties + hooks for most of what you want to do. > > Window properties are not powerful per se. You have to modify Emacs' > primitives to give them power. Currently, a package like ECB does this > by advising these primitives. Hooks are something I use in my private > programs. As for functions shipped with Emacs I prefer them _not_ use > any hook unless there's no other way. Maybe a rule of thumb is that it is reasonable to use a hook if it also makes sense to remove the hook function you are installing. That is, a hook function whose absence would break emacs suggests a function that shouldn't be run from the hook but in some other way. But, aren't there even exceptions to that rule of thumb in the core? I don't clearly remember that detail. > > > 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. > > I didn't say they "don't have a reasonable solution". I said it's hard > to specify them in a few lines. Sorry, those two are almost (*almost*) synonymous to me :-) The really charming bits of Emacs seem to me to be the startlingly simple yet powerful/general/flexible bits. > What's worse, in my opinion, is that we > currently don't have any visual feedback. A user who wants to operate > on a group of windows usually can tell the members of that group only by > intuition. If you already don't recognize plain groups then how about > nested ones? What's the purpose of a concept if the user can't grasp > it? We agree on some aspects of UI. I like the way you put that. If you want to get to a UI that presents easy concepts for users to grasp, the thing that works well (especially in the Emacs tradition) is for the underlying program to have very simple-minded data structures. Then, the UI is just "drawing pictures" of something that is already simple. The way people go wrong is when they think of some "simple for users" concept that, it turns out, requires a lot of strange complexity in the code. What often happens there is that the UI is then drawing a falsely simple picture -- illustrating a fantasy -- and the underlying code can "fake it" to an extent but never quite live up to it. I call these "user interfaces that lie". You're a little too casual, in my opinion, with the notion of a "group". I think you might be adding hair to the code and a UI that dissembles a bit. But I do strongly agree that the ultimate aim here is just to give a gadget (underlying code) whose form and therefore function is transparent (UI) to the users. (Geeze, I sound like from Palo Alto with this level of pretension :-) > > > 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*. > > It certainly should. That's why I don't like a solution which always > throws me back to a static (previously defined and explicitly saved) > window configuration. I want dynamic configurations much as Emacs > permits me to create them now, possibly embedded in an edit area and > surrounded by view windows I can create and dismiss at will. So do I and I think that's what I've been sketching. > > >> 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? > > For obvious reasons these examples reside on my system only. Most of > these are concerned with usually two or three sidebars (narrow windows) > distributed all over my frame. Each of these sidebars is the left > window in a combination with some client window and gives me details of > what I show or eventually might want to show in the client window > (files, buffers, tags, bookmarks, search results). Sidebar and client > window form a group and their relationship can't get broken by > extraneous functions like `display-buffer' or `split-window'. And I can > have as many such groups as the resolution of my screen and my eyesight > permit. Ok, if I understand that right I'm pretty sure that "groups" aren't the most parsimonious approach although I can see why they would work. I'd like to suggest that the windows you want to "protect" with groups don't actually need protection. If the user does stuff that f-s with them, so be it. I think that instead of that kind of protection you just want "encouragement" for normal commands to not perturb them. Pop-ups other than leaf nodes and window props should do the trick. It's ok for a fancy, app-defined window-config to sometimes "fall apart" if there's an easy way to restore it and it doesn't fall apart accidentally very often, especially if the return for that is keeping the "concept model" of the display simple. > > > 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 `split-window' changes are sane since they are based on three > optional argument. If you don't set eiher of them, the behavior of > `split-window' is unaffected. "straightforward" here just stands for > "it wasn't difficult to do that". Their sane in that they preserve a default behavior. One view of the problem is: will your successor, in 10 years, feel good about preserving the behavior of these three new parameters plus all the twisted, unanticipated uses people have put them to? > > > 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) > [...] > > > > 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 :-) > > Window groups are an abstraction. Their purpose is to provide some of > the functionality of window trees. But users should not be aware of > thses underlying trees at all. I give you an example: Create a layout > by subdividing a fresh frame via C-x 2 C-x 3 C-x 2 C-x 3. Go to the > upper right window and repeatedly call the function > > (defun my-enlarge-window-horizontally () > (interactive) > (let ((window-min-width 1)) > (enlarge-window 1 t))) > > You will observe the upper left windows shrink and, at a certain moment, > the three windows in the upper left corner disappear all together > although it would have been sufficient to delete just one of the two > smallest windows. Explaining this behavior is very difficult and > intrinsically tied to the fact that the shrink_windows routine in > window.c does not recurse but operate on window combinations only. See above about "protection". > > Now don't get me wrong. I don't consider this behavior a bug. After > all, if a window gets deleted because there's no other way out, why not > delete a couple of other windows as well. I still consider Emacs' > behavior quite sane here. The point I wanted to make is that > understanding and implementing window trees is already pretty hard for > developers. Exposing them to the user simply doesn't make sense, IMHO. > > >> 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. > > If your edit area appears like this > > ----- > | | | > | | | > ----- > > and you consider it a "stack" (actually a "deque") you supply the > connotation that any further split has to occur on one of each sides. > But what if you want to split one of these windows vertically? What if > you want a compile, shell, or help window at the bottom? You'll tell me > that you'd create another stack embedded in or on top of the previous > one. In my parlance any combination of such stacks is a window group. > > I don't see any reason for "groups" to be a first-class notion in lisp or in the "user's cognitive model". It's just tiling. It's not too complicated for non-programmer users to get, is the experience here. Finally: thank you for taking the time to reply. I think I want to back off this topic a little bit and, perhaps, tinker with setting up a dev tree for myself. *If* I get around to that, it might make these conversations easier. -t