From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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:34:21 +0200 Message-ID: <4815EE7D.6020304@gmx.at> References: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429A02@mucmail3.sdm.de> <84D8FEFE8D23E94E9C2A6F0C58EE07E3429AF9@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 1209396929 30100 80.91.229.12 (28 Apr 2008 15:35:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2008 15:35:29 +0000 (UTC) Cc: ecb-list@lists.sourceforge.net, joakim@verona.se, emacs-devel@gnu.org To: klaus.berndl@sdm.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 28 17:36:04 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 1JqVOL-00052M-47 for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2008 17:35:45 +0200 Original-Received: from localhost ([127.0.0.1]:47210 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqVNe-0007K6-CT for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2008 11:35:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JqVNa-0007JK-5l for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:34:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JqVNZ-0007J8-Nm for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:34:57 -0400 Original-Received: from [199.232.76.173] (port=49354 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqVNZ-0007J5-I1 for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:34:57 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JqVNZ-0000q7-En for emacs-devel@gnu.org; Mon, 28 Apr 2008 11:34:57 -0400 Original-Received: (qmail invoked by alias); 28 Apr 2008 15:34:55 -0000 Original-Received: from 88-117-46-30.adsl.highway.telekom.at (EHLO [88.117.46.30]) [88.117.46.30] by mail.gmx.net (mp046) with SMTP; 28 Apr 2008 17:34:55 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19lEVRgSqJlvWC3W/5C2mp4h4Xm2sLQl0T8ZK/XCU ShwRqfdskNqcm5 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <84D8FEFE8D23E94E9C2A6F0C58EE07E3429AF9@mucmail3.sdm.de> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:96073 gmane.emacs.code-browser:2118 Archived-At: > 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... 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? > 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: 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? What mechanism do you use to access a window outside the edit-area - do you suspend advices? > 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? 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. Do you want the edit-area occasionally occupy the entire frame? > 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... Couldn't this be done with the help of a `switch-buffer-function'? > 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... 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".