[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Neat features in Eclipse editor

From: joakim
Subject: Re: Neat features in Eclipse editor
Date: Sun, 23 Mar 2008 10:53:20 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.60 (gnu/linux)

Juri Linkov <address@hidden> writes:

>>> * "Perspectives" are named persistent window configurations.  We have
>>> had the window configuration mechanism in GNU Emacs since the
>>> beginning but we have never developed a good user interface to take
>>> advantage of them.  Eclipse's user interface seems to be good.

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.

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.

The Emacs ECB package is designed to do all of this in Emacs. It has been
discussed for inclusion. It uses lots and lots of advice to achive the
sub-frame feature. Recently I did a small review of the code to see if
it would be possible for me to remove the advice, by providing suitable
hooks in Emacs. It did not apear immediately obvious how to do this.

I'm now thinking it would be easier to start by providing a C
level interface, and then adjust the ECB to use this interface.

Heres what I thought could be done:

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

- as an example, I now create 2 subframes called left and right.  When
I'm in the left sub-frame and do other-window, I only jump between
windows in the left sub-frame. Likewise for the right sub-frame. When I
do delete-other-windows, only other windows in the sub-frame goes away.

Again, this is achieved by all window functions looking at the list of
windows in the sub-frame structure rather than the frame structure.

Moving between sub-frames needs a new function similar to other-frame.

Does this sound at all feasible? 

Joakim Verona

reply via email to

[Prev in Thread] Current Thread [Next in Thread]