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: AW: Infrastructural complexity. Date: Fri, 24 Jul 2009 18:09:44 +0200 Message-ID: <4A69DCC8.6000506@gmx.at> References: <20090712180623.GA1009@muc.de> <4A67593D.6020908@gmx.at><1248289454.7109.47.camel@dell-desktop.example.com><4A682C53.2080307@gmx.at><1248375083.15583.9.camel@dell-desktop.example.com><4A6970CA.7090006@gmx.at><4A69A4C1.1010408@gmx.at> <84D8FEFE8D23E94E9C2A6F0C58EE07E3034461C8@mucmail3.sdm.de> 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 1248451872 17298 80.91.229.12 (24 Jul 2009 16:11:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2009 16:11:12 +0000 (UTC) Cc: lord@emf.net, rms@gnu.org, cyd@stupidchicken.com, lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, juri@jurta.org, monnier@iro.umontreal.ca, acm@muc.de, drew.adams@oracle.com, miles@gnu.org To: klaus.berndl@capgemini-sdm.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 24 18:11:03 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 1MUNMJ-0006AY-9k for ged-emacs-devel@m.gmane.org; Fri, 24 Jul 2009 18:10:59 +0200 Original-Received: from localhost ([127.0.0.1]:36339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUNMI-00009A-IN for ged-emacs-devel@m.gmane.org; Fri, 24 Jul 2009 12:10:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUNLH-0007NF-FJ for emacs-devel@gnu.org; Fri, 24 Jul 2009 12:09:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUNLC-0007I9-Mx for emacs-devel@gnu.org; Fri, 24 Jul 2009 12:09:55 -0400 Original-Received: from [199.232.76.173] (port=47355 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUNLC-0007Gx-Ea for emacs-devel@gnu.org; Fri, 24 Jul 2009 12:09:50 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:49228) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MUNLB-00052e-5k for emacs-devel@gnu.org; Fri, 24 Jul 2009 12:09:49 -0400 Original-Received: (qmail invoked by alias); 24 Jul 2009 16:09:47 -0000 Original-Received: from 62-47-37-184.adsl.highway.telekom.at (EHLO [62.47.37.184]) [62.47.37.184] by mail.gmx.net (mp055) with SMTP; 24 Jul 2009 18:09:47 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18hPboFZlchUfDfO0PkUsPPjXMUA6Wd0IVnoiLQJw viM+p0ugCnBlrS User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <84D8FEFE8D23E94E9C2A6F0C58EE07E3034461C8@mucmail3.sdm.de> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:113103 Archived-At: > With such a window-group concept several things should/could be possible: > - preventing a group from being be deleted by C-x 1 (AFAIK currently > there is something going on to achieve this with a new window-flag, This would be done with a window parameter of the internal window group window (that parameter would have to be installed by ECB to become effective) and an appropriate change of `delete-other-windows'. BTW, I suppose you mean that C-x 1 invoked within a window belonging to a window group just deletes all other windows of that group? > IIRC implemented by Joakim for the next release 24.X?!) > - hiding (ie. deleting) a window-group (ie. all it's windows but no others > from outside the group) Here this is simply `delete-window' applied to the internal window constituting the group (some other window must be left on the frame to make this happen). > - saving the window-configuration of exactly one group and restoring only this > window-group (if a frame allocates needed space) I suppose you mean saving the group configuration, that is, windows not belonging to the group are not saved. This can be done and you can restore them in an arbitrary window (like the root window of a frame or an arbitrary other window). > - rewriting display-buffer so only a certain window-group can be > used for displaying a buffer - or the other direction: a window-group can > be prevented from being used by display-buffer for buffer display The "other direction" solution will be preferred, probably. This means a slight change in testing whether a window `display-buffer' chooses can really be used. > - etc... > > IMHO such a general window-group concept between the frame- and the window- > concept would alleviate writing a tool like ECB (and would make a lot of its > advices obsolete or at least much simpler) I suppose we must get rid of all advices. > This is the point of view of the author and maintainer of ECB ;-) The more complete the list of issues you sketched above gets, the better I can try to address these issues early enough. martin