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:58:51 +0200 Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429DDD@mucmail3.sdm.de> References: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429A02@mucmail3.sdm.de> <84D8FEFE8D23E94E9C2A6F0C58EE07E3429AF9@mucmail3.sdm.de><4815EE7D.6020304@gmx.at> <84D8FEFE8D23E94E9C2A6F0C58EE07E3429DD9@mucmail3.sdm.de> 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 1209398398 3531 80.91.229.12 (28 Apr 2008 15:59:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2008 15:59:58 +0000 (UTC) Cc: emacs-devel@gnu.org, joakim@verona.se, ecb-list@lists.sourceforge.net To: , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 28 18:00:33 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 1JqVla-0006Kx-54 for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2008 17:59:46 +0200 Original-Received: from localhost ([127.0.0.1]:51755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqVkt-0005Zv-KD for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2008 11:59:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JqVko-0005Zo-7k for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:58:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JqVkm-0005YU-Bm for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:58:56 -0400 Original-Received: from [199.232.76.173] (port=44982 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqVkm-0005YN-8f for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:58:56 -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 1JqVkl-00070f-U3 for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:58:56 -0400 Original-Received: from mucns1 ([10.40.232.18] helo=mucns1.sdm.de) by world2.sdm.de with esmtp (MTA) id 1JqVkk-0007JH-78; Mon, 28 Apr 2008 17:58:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=sdmmail1.sdm.de) by mucns1.sdm.de with esmtp (MTA) id 1JqVkk-0007Kf-7m; Mon, 28 Apr 2008 17:58:54 +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:58:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message In-Reply-To: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429DD9@mucmail3.sdm.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch for optional inhibit of delete-other-windows(IDE feature) Thread-Index: AcipRXD3amJ1EbQrQumG9r3hrBLr3wAALB9QAACRTQA= X-OriginalArrivalTime: 28 Apr 2008 15:58:53.0520 (UTC) FILETIME=[C1DBB500: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:96076 gmane.emacs.code-browser:2120 Archived-At: klaus.berndl@sdm.de wrote: > 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? >=20 > Currently the concept of ECB is: > - Exactly one frame sorry, misunderstandable: Must be: Exactly one frame *for ECB* (of course there can be opened other coexistent frames used for 'not-ECB-editing' - all ECB-operations always affect the ECB-frame, no other frame, all adviced are 100% save concerning this) > - 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 >>=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 >>=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? >=20 > 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 >=20 >> What mechanism do you use to access a window outside the >> edit-area - do you suspend advices? >=20 > What do you mean with "access"? >=20 >>=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. >=20 > 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 > 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...=20 >=20 >> Do you want the edit-area occasionally occupy the entire frame? >=20 > 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'? >=20 > Yes, probably this would be possible! >=20 >>=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". >=20 > yes, this was my intention - see above... >=20 > Klaus