From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Sat, 18 Jul 2009 15:49:41 +0200 Message-ID: <4A61D2F5.3030109@gmx.at> References: <20090712180623.GA1009@muc.de> <1247784574.6302.83.camel@dell-desktop.example.com> <1247787842.6302.90.camel@dell-desktop.example.com> <1247793496.6302.112.camel@dell-desktop.example.com> <1247797261.6302.137.camel@dell-desktop.example.com> <1247798678.6302.156.camel@dell-desktop.example.com> <87ocrjtafd.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1247925143 16780 80.91.229.12 (18 Jul 2009 13:52:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jul 2009 13:52:23 +0000 (UTC) Cc: Thomas Lord , Lennart Borgman , joakim@verona.se, emacs-devel@gnu.org, Juri Linkov , Stefan Monnier , Alan Mackenzie , Drew Adams To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 18 15:52:15 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 1MSAKk-0000xp-Ek for ged-emacs-devel@m.gmane.org; Sat, 18 Jul 2009 15:52:14 +0200 Original-Received: from localhost ([127.0.0.1]:40480 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSAKj-00060X-Sw for ged-emacs-devel@m.gmane.org; Sat, 18 Jul 2009 09:52:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MSAIX-00031B-S1 for emacs-devel@gnu.org; Sat, 18 Jul 2009 09:49:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MSAIS-0002w6-SY for emacs-devel@gnu.org; Sat, 18 Jul 2009 09:49:57 -0400 Original-Received: from [199.232.76.173] (port=51369 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSAIS-0002vx-Mp for emacs-devel@gnu.org; Sat, 18 Jul 2009 09:49:52 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:50733) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MSAIR-0000nf-4f for emacs-devel@gnu.org; Sat, 18 Jul 2009 09:49:51 -0400 Original-Received: (qmail invoked by alias); 18 Jul 2009 13:49:49 -0000 Original-Received: from 88-117-40-129.adsl.highway.telekom.at (EHLO [88.117.40.129]) [88.117.40.129] by mail.gmx.net (mp009) with SMTP; 18 Jul 2009 15:49:49 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+pBuRpwCCpmmBNAONQMLCP/Nw5Ly3m/EBz9CnEsM jqs9z1+fqp9ItO User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87ocrjtafd.fsf@stupidchicken.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 X-detected-operating-system: 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:112680 Archived-At: > I recall that we had an inconclusive discussion over the relative merits > of two proposals, one by Joakim that (IIRC) relied on window parameters, > and another by Martin that uses more built-in code. Does anyone have > any new thoughts about this? From earlier discussions I'm fairly convinced of one thing: A window group should correspond to an internal window. IIRC Klaus Berndl confirmed that ECB configurations always form rectangles so there should not be problems with ECB. If, however, someones wants to combine non-rectangular subregions of a frame to form a group, this approach won't work (in that case, however, a number of features like cloning a window group into a separate frame would have no intuitive solution anyway). FWIW, the following issues are still unresolved: - Whether we should allow nested or intersecting window groups. This is a fundamental issue. - Whether we want special naming conventions for window groups and whether we should permit unnamed window groups. This is not a serious issue since all this can be easily resolved on top of internal windows but would be good to know. - Whether, which and how window properties (fixed-size, dedicated, ...) apply to window groups. This is a subtle issue since a fixed-size window group should probably allow to vary the sizes of the individual windows within the group but not the size of the rectangle covered by the group. A dedicated window group would likely forbid to replace the entire rectangle by something else and allow to replace the contents of individual members of the group but this seems far less intuitive already. - Whether and how window groups interact with window parameters: We can easily extend window parameters to apply to internal windows and, as a rule, store all group relevant information there - like, for example, whether `delete-other-windows' invoked within a window of a group should delete all other members of that group or all other windows of the containing frame. - Whether and how window groups can be distinguished visually within the containing frame. martin