[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: window groups
Re: window groups
Mon, 02 Jun 2008 14:32:27 -0700
Thunderbird 184.108.40.206 (X11/20060808)
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
> 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
> I am proposing that, using window
> properties and various hooks, a user should be able to delete that
> and restore the previous window configuration of the same frame
> 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
> 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
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
> 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
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
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
can "fake it" to an extent but never quite live up to it. I call these
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,
> 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
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
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
> over-supply of the "straightforward change" but, experience shows,
> tiny fraction of those changes are comfortable in the long run -- the
> 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
> 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
> navigate the tree. This would be a lot easier to talk about at
> 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 ()
(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
- Re: window groups, Thomas Lord, 2008/06/01
- Re: window groups, martin rudalics, 2008/06/02
- Re: window groups,
Thomas Lord <=
- Re: window groups, Miles Bader, 2008/06/03
- Re: window groups, martin rudalics, 2008/06/03
- Re: window groups, René Kyllingstad, 2008/06/03
- Re: window groups, martin rudalics, 2008/06/03
- Re: window groups, Stephen Berman, 2008/06/03
- Re: window groups, René Kyllingstad, 2008/06/03
- Re: window groups, Stefan Monnier, 2008/06/07