[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Neat features in Eclipse editor
From: |
Richard Stallman |
Subject: |
Re: Neat features in Eclipse editor |
Date: |
Sun, 23 Mar 2008 20:54:07 -0400 |
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.
- Re: Neat features in Eclipse editor, (continued)
- Re: Neat features in Eclipse editor, joakim, 2008/03/23
- Re: Neat features in Eclipse editor, martin rudalics, 2008/03/23
- Re: Neat features in Eclipse editor, martin rudalics, 2008/03/23
- Re: Neat features in Eclipse editor, John S. Yates, Jr., 2008/03/23
- Re: Neat features in Eclipse editor, Thomas Lord, 2008/03/23
- Re: Neat features in Eclipse editor, John S. Yates, Jr., 2008/03/23
- Re: Neat features in Eclipse editor, Thomas Lord, 2008/03/23
- RE: Neat features in Eclipse editor, Drew Adams, 2008/03/23
- Re: Neat features in Eclipse editor, dtm, 2008/03/25
- Re: Neat features in Eclipse editor, Stefan Monnier, 2008/03/23
- Re: Neat features in Eclipse editor,
Richard Stallman <=
- Re: Neat features in Eclipse editor, joakim, 2008/03/24
- Re: Neat features in Eclipse editor, Bastien, 2008/03/24
- Re: Neat features in Eclipse editor, Richard Stallman, 2008/03/25
- Re: Neat features in Eclipse editor, Rajappa Iyer, 2008/03/25
- Re: Neat features in Eclipse editor, Stefan Monnier, 2008/03/25
- Re: Neat features in Eclipse editor, Richard Stallman, 2008/03/26
- Re: Neat features in Eclipse editor, Richard Stallman, 2008/03/24
Re: Neat features in Eclipse editor, Richard Stallman, 2008/03/23