From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel,gmane.emacs.code-browser Subject: RE: patch for optional inhibit of delete-other-windows(IDE feature) Date: Mon, 28 Apr 2008 17:55:06 +0200 Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429DD9@mucmail3.sdm.de> References: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429A02@mucmail3.sdm.de> <84D8FEFE8D23E94E9C2A6F0C58EE07E3429AF9@mucmail3.sdm.de> <4815EE7D.6020304@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1209398260 2970 80.91.229.12 (28 Apr 2008 15:57:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2008 15:57:40 +0000 (UTC) Cc: ecb-list@lists.sourceforge.net, joakim@verona.se, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 28 17:58:16 2008 connect(): Connection refused 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 1JqVhw-0004ag-Bz for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2008 17:56:00 +0200 Original-Received: from localhost ([127.0.0.1]:44691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqVhF-00044J-Sd for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2008 11:55:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JqVhB-00044C-OB for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:55:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JqVhA-000440-8Q for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:55:12 -0400 Original-Received: from [199.232.76.173] (port=50043 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqVhA-00043x-0x for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:55:12 -0400 Original-Received: from world2.sdm.de ([192.76.162.230]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JqVh9-00069z-Lk for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:55:12 -0400 Original-Received: from mucns1 ([10.40.232.18] helo=mucns1.sdm.de) by world2.sdm.de with esmtp (MTA) id 1JqVh7-0006gs-QK; Mon, 28 Apr 2008 17:55:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=sdmmail1.sdm.de) by mucns1.sdm.de with esmtp (MTA) id 1JqVh7-0007Dv-MT; Mon, 28 Apr 2008 17:55:09 +0200 Original-Received: from mucmail3.sdm.de ([10.40.232.45]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 17:55:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message In-Reply-To: <4815EE7D.6020304@gmx.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch for optional inhibit of delete-other-windows(IDE feature) Thread-Index: AcipRXD3amJ1EbQrQumG9r3hrBLr3wAALB9Q X-OriginalArrivalTime: 28 Apr 2008 15:55:08.0960 (UTC) FILETIME=[3C029200:01C8A948] X-detected-kernel: by monty-python.gnu.org: 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:96075 gmane.emacs.code-browser:2119 Archived-At: martin rudalics wrote: > > Hmm, its a good starting point but not complete. Simply think of > ECB > as a tool which wants to display some special windows beside an > > "edit-area" whereas the former one are used to display > informational > context stuff as parsed tags of the current buffer > in the edit-area > or a file- and directory tree or a buffer-history > or or or... > The latter one (the edit-area) should give the user > the feeling as > if all windows of this edit-area would be the only > windows in the > frame so all standard operations would act as if > the edit-windows > would be the only windows in the frame... >=20 > Is the edit-area always a rectangle? Can it be always created by > recursively subdividing an initial window? Is there always at most > one edit-area? Is there at most one edit-area in one and the same > frame?=20 To all questions: YES, except the recursively subdividing one: What do you mean exactly? Currently the concept of ECB is: - Exactly one frame - The is *always* exact ONE edit-area, which is always a rectangle - The special windows are located either at the left, at the right or on top of the edit area - the edit-arey can be subdivided in as many windows as possible >=20 > > Well, a window property for preventing other windows outside the > > edit-area from being deleted or for a navigation only in the edit- > > area by other-window would be a good starting point but its not the > > end of the story: >=20 > Can all operations you need be subdivided into whether they either > apply to all windows in the edit-area or to all windows outside the > edit-area? Almost: Currently ECB needs three canonical window-lists: - full window list of the ECB-frame - all windows in the edit-area - all special ECB-windows - the compile-window (always displayed at bottom) when displayed canonical means: always the same sequence beginning from top/left-most, ie. the same order an unadviced version of `next-window' would walk through >What mechanism do you use to access a window outside the > edit-area - do you suspend advices? What do you mean with "access"? >=20 > > What about saving and later restoring the current window layout of > the > edit-area (means only these windows inside the edit-area) > without > affecting the layout of the special windows? >=20 > Do you also need to save and restore the layout of the non-edit-area? > Earlier I got the impression that the non-edit-area would be > immutable, so you could easily include it in the saved configuration. Yes, currently the layout of the non-edit-area is immutable in this sense that redrawing the whole layout of the ECB-frame resizes the special windows back to their cusomized (via customize) sizes (can be absolute or - prefered - relative) whereas the sizes=20 of the windows in the edit-area will be preserved by a layout-redraw, means the sizes the user has choosen by dragging modeline or what = else... > Do you want the edit-area occasionally occupy the entire frame? Yes, there is a command which allows to hide or to toggle visibility of the special windows - you can imagine that this needs complex and smart code-stuff to preserve the window-layout of the edit-area during that, but it works stable and error-less... IMHO temporarly hidding the special windows (ie. only the edit-area and all its windows are visible in the ECB-frame) is a very important feature of an IDE...=20 >=20 > > And how to implement an option like > > `ecb-layout-always-operate-in-edit-window' > > (see docstring) without adviceing e.g. switch-to-buffer? > > > > Just take a look at the docstring of the adviced > `switch-to-buffer': > IMHO even with the new pins advices are needed > to offer a smart and > convenient usage of an IDE like ECB... >=20 > Couldn't this be done with the help of a `switch-buffer-function'? Yes, probably this would be possible! >=20 > > maybe i will find next weekend the needed time to write down a > small > "functional reqirement specification" which core > functionality would > be required by Emacs to rewrite ECB without a > lot of its advices or > at least with much simpler advices... >=20 > If possible, please list also invariants which can be used to cut down > the overhead for providing these requirements. Like "for any frame > the number of edit-areas it displays is zero or one". yes, this was my intention - see above... Klaus