From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Neat features in Eclipse editor Date: Sun, 23 Mar 2008 20:54:07 -0400 Message-ID: References: <873aqia0eh.fsf@stupidchicken.com> <873aqiw4xm.fsf@jurta.org> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1206320096 13595 80.91.229.12 (24 Mar 2008 00:54:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2008 00:54:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 24 01:55:25 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 1Jday8-0007a6-BZ for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2008 01:55:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdaxX-0007IY-KD for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 20:54:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jdawz-0006so-Uv for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:54:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jdawy-0006s5-8O for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:54:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jdawy-0006rz-0P for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:54:08 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jdawx-0007q2-MZ for emacs-devel@gnu.org; Sun, 23 Mar 2008 20:54:07 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Jdawx-0006Uj-06; Sun, 23 Mar 2008 20:54:07 -0400 In-reply-to: (joakim@verona.se) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:93279 Archived-At: 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.