Re: Neat features in Eclipse editor

[Richard Stallman]

    Eclipse, and nearly all other IDE:s also have the feature that the main
    frame is sub-divided in minor frames that dont affect each other.

Could you explain more concretely what these "minor frames" look like,
and what "don't affect each other" means?

    That is, I have an editor sub-frame, and a compilation message sub-frame
    etc. If I remove an editor tab in the editor sub-frame, this doesnt
    affect the other parts of the master frame.

When I try to relate this to what I saw, it seems that what you call
"sub-frames" looked like windows to me.  Why do you call them
"sub-frames" instead of "windows"?  The term "sub-frames" implies a
big change.

To give each window in its own list of tabs would be a fairly small
change in Emacs (assuming that we have tabs at all).

Is more than that needed?

    - Create a new Emacs window object called a sub-frame. This sits between
    frames and windows. It nominaly provides a list of windows like a frame
    does and is normaly the same list of windows the frame has. A frame can
    have several sub-frames, but at the start only one. When no sub-frame
    features are used, emacs behaves exactly as it does today.

This seems like a plausible implementation of a sub-frame feature.  Do
we really need this feature, or would it be enough to give each window
its own list of tabs?

    When I
    do delete-other-windows, only other windows in the sub-frame goes away.

If most of the windows are dedicated, delete-other-windows would not
touch them.  Is that sufficient for the job?

If not, here's a simple way to take care of that.

Emacs windows within a frame form a tree.  We could add a way to mark
a certain non-leaf window as a "sub-frame", such that when the
selected window is a subwindow of that, certain operations including
delete-other-windows would be limited to the inside of that sub-frame.

This could be a rather simple change to implement sub-frames, if we
need the power of sub-frames.

Is this enough to implement perspectives?

Adding a new data type with new operations is certainly possible,
but it is expensive in several ways, so we should do that only
if a simpler adequate solution can't be found.