Re: Neat features in Eclipse editor

[joakim@verona.se]

Richard Stallman <rms@gnu.org> writes:

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

I will try.

Imagine several Emacs frames that are laid out next to each other, for
instance like this:

+---+-------------+
| 1 | 2           |
|   |             |
|   |             |
+---+-------------+
| 3               |
+-----------------+


Frame 1 contains the emacs Speedbar, which gives a tree view of code,
which is displayed in frame 2.
frame 3 shows compilation output.

This is similar to what ECB does, and also a common Eclipse perspective.

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

Sub-frames are not like windows, they are like frames, because they
contain windows and are not affected by what happens in other frames.

Tabs are usually complementary to the feature I try describe.

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

Maybe. I can't recall an Emacs application that uses dedicated windows
right now, so I'm not sure how they function in practice.

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

Sounds plausible. I didnt know Emacs windows existed in a tree structure.

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

I agree of course.

-- 
Joakim Verona