Re: window groups

[martin rudalics]

> 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 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.

> 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.

> 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.)

> 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.

> 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.  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?

> 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.

>> 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.

>> 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 :-)

I use "safe" for "not breaking Emacs" and "sane" for "not breaking the
editing habits of Emacs users".

> 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".

>> 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.

IMHO cloning must come in two flavors: The first means to recreate a
layout in one and the same session.  In this case you want cloning to
happen quickly and match the original layout as sincerely as possible
(just like `set-window-configuration').  The second flavor comes for
recreating frame layouts in another session, on another system, for
another user.  In that case cloning may be slower since it's based on
recursively applying `split-window' and maybe less faithful to the
original because the enironment might have changed.

> 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.

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.