From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Thu, 16 Jul 2009 15:49:34 -0700 Message-ID: <1247784574.6302.83.camel@dell-desktop.example.com> References: <20090712180623.GA1009@muc.de> <53864.130.55.118.19.1247586358.squirrel@webmail.lanl.gov> <87r5whgzvg.fsf@mail.jurta.org> <0C244EB2B99349238E281268B0339C72@us.oracle.com> <20090716200959.GA4298@muc.de> <87vdlstkg4.fsf@mail.jurta.org> <87skgwb9na.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1247784596 8771 80.91.229.12 (16 Jul 2009 22:49:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jul 2009 22:49:56 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org, Juri Linkov , Stefan Monnier , Alan Mackenzie , Drew Adams To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 17 00:49:48 2009 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 1MRZlr-0004MT-Pb for ged-emacs-devel@m.gmane.org; Fri, 17 Jul 2009 00:49:48 +0200 Original-Received: from localhost ([127.0.0.1]:38835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRZlr-0000MP-3B for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2009 18:49:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRZlk-0000MK-QK for emacs-devel@gnu.org; Thu, 16 Jul 2009 18:49:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRZlh-0000LY-0M for emacs-devel@gnu.org; Thu, 16 Jul 2009 18:49:40 -0400 Original-Received: from [199.232.76.173] (port=38275 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRZlg-0000LV-R3 for emacs-devel@gnu.org; Thu, 16 Jul 2009 18:49:36 -0400 Original-Received: from smtp121.iad.emailsrvr.com ([207.97.245.121]:58336) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRZlg-0004Oj-HY for emacs-devel@gnu.org; Thu, 16 Jul 2009 18:49:36 -0400 Original-Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id B8B2C1B4028; Thu, 16 Jul 2009 18:49:35 -0400 (EDT) Original-Received: by relay22.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 5ACE01B4020; Thu, 16 Jul 2009 18:49:34 -0400 (EDT) In-Reply-To: X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/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:112575 Archived-At: On Fri, 2009-07-17 at 00:14 +0200, Lennart Borgman wrote: > There is no "protected windows" yet, but ECB tries to implement them. > It is windows that are not affected by window commands that deletes > windows, like C-x 1, C-x 0. If (and it's a moderately sized "if") I understand correctly what functionality is desired, I think that there is a cleaner approach: hack frames, not windows. How about: A "frame" is a frame, essentially like today. Except: A "framelette" is like a frame, except that it is a child of a frame. Every frame has exactly four framelettes, always: Two framelettes at the top and and bottom of the frame, one just below where menus go, the other just above where the minibuffer goes. Two framelettes at the left and right edges, bordered above and below by the top and bottom framelettes. Framelettes can not be created or deleted other than by making a new frame or killing an old frame. The window configuration of a framelette can be nil, in which case the framelette is not displayed. The rectangle left in the middle, bounded on all sides by the four framelettes, is where the windows of the frame go. A command like C-x 1 clears just that one rectangle, at least if invoked from within that rectangle. If a window in a framelette is selected, then "selected-frame" gives the framelette, not the parent frame. DELETE-FRAME in a framelette does not actually delete the frame, it only sets its window configuration to nil and selects a window in the middle of the parent frame. Trying to hack what I think you are trying to do just at the window level seems like it will overly complicate the problem of coming up with a better window configuration system. Hacking it at the frame level and keeping it simple with just the four framelettes seems like you an do all the neat IDE GUIish stuff without too badly mucking up long-standing abstractions. I would expect the modes most often used in buffers whose windows live in framelettes to not treat commands like C-x 1 quite normally - but they can do that easily without horking too badly what such commands normally mean. -t > > I have no idea what we will call, that is why I gave a pointer to ECB, > but of course only those that are familiar with ECB will understand > me. Sorry. > > There was a long discussion of this feature here some time ago. ECB > uses advice to achieve this now. The solution is surpricingly good, > but there are some smaller irritating problems with it of course.