From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Neat features in Eclipse editor Date: Sun, 23 Mar 2008 10:53:20 +0100 Message-ID: References: <873aqia0eh.fsf@stupidchicken.com> <873aqiw4xm.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1206266197 12469 80.91.229.12 (23 Mar 2008 09:56:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Mar 2008 09:56:37 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 23 10:57:07 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JdMws-0008Tq-44 for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 10:57:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdMwH-0003MT-73 for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 05:56:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JdMwC-0003LE-Tp for emacs-devel@gnu.org; Sun, 23 Mar 2008 05:56:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JdMw8-0003JF-MN for emacs-devel@gnu.org; Sun, 23 Mar 2008 05:56:23 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdMw8-0003JB-JY for emacs-devel@gnu.org; Sun, 23 Mar 2008 05:56:20 -0400 Original-Received: from iwfs.imcode.com ([82.115.149.64] helo=gate.verona.se) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JdMw8-0004d5-4o for emacs-devel@gnu.org; Sun, 23 Mar 2008 05:56:20 -0400 Original-Received: from chopper (IDENT:1005@localhost [127.0.0.1]) by gate.verona.se (8.13.4/8.11.4) with ESMTP id m2N9uEQZ026124 for ; Sun, 23 Mar 2008 10:56:15 +0100 In-Reply-To: <873aqiw4xm.fsf@jurta.org> (Juri Linkov's message of "Sun, 23 Mar 2008 04:27:17 +0200") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:93249 Archived-At: Juri Linkov 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