From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Neat features in Eclipse editor Date: Sun, 23 Mar 2008 20:53:08 -0400 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 1206320003 13420 80.91.229.12 (24 Mar 2008 00:53:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2008 00:53:23 +0000 (UTC) Cc: emacs-devel To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 24 01:53:53 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 1Jdawi-0007IU-0y for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2008 01:53:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jdaw7-0006Kj-37 for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 20:53:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jdaw3-0006KZ-2Z for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:53:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jdaw1-0006K1-Je for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:53:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jdaw1-0006Jy-H0 for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:53:09 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jdaw1-0007dA-4K for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:53:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUHAIeY5kdMCrTo/2dsb2JhbACBW6Qn X-IronPort-AV: E=Sophos;i="4.25,544,1199682000"; d="scan'208";a="16444052" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 23 Mar 2008 20:53:08 -0400 Original-Received: from pastel.home ([76.10.180.232]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id EDZ64008; Sun, 23 Mar 2008 20:53:08 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 47BD77F18; Sun, 23 Mar 2008 20:53:08 -0400 (EDT) In-Reply-To: (joakim@verona.se's message of "Sun, 23 Mar 2008 10:53:20 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:93277 Archived-At: > 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. There are a few packages that like to take control of a frame and display various windows inside. Gnus and gdb-ui come to mind. Similarly, users (and commands by default) often like to control the frame as a whole, without much regard for the various windows already present, assuming that minor changes aren't important as long as the user can adjust them later. ECB's effort in this is very valuable. It would be good to provide some kind of functionality to make ECB's task easier and to make it possible for users to give a sub-part of a frame to Gnus. I'm not sure if that should be provided via a new concept of "subframe", or by making it possible to collocate several frames together (within the same GUI window). Maybe a lightweight approach would be to be able to tag each and every window with a "subframe" property, such that a "subframe" is simply the set of windows with the same "subframe" value. The only problem with all of that, is the added complexity. E.g. Are we going to have a family of functions FOO-BAR-other-subframe? Stefan