From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: RE: ECB Date: Tue, 7 Mar 2006 14:48:10 +0100 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1141748659 1454 80.91.229.2 (7 Mar 2006 16:24:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 7 Mar 2006 16:24:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 07 17:24:16 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FGeye-0007NO-Nj for ged-emacs-devel@m.gmane.org; Tue, 07 Mar 2006 17:24:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FGeye-0008VY-0u for ged-emacs-devel@m.gmane.org; Tue, 07 Mar 2006 11:24:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FGcY3-0001dW-Qf for emacs-devel@gnu.org; Tue, 07 Mar 2006 08:48:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FGcY2-0001YK-Nx for emacs-devel@gnu.org; Tue, 07 Mar 2006 08:48:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FGcY2-0001WZ-Ic for emacs-devel@gnu.org; Tue, 07 Mar 2006 08:48:22 -0500 Original-Received: from [192.76.162.229] (helo=world1.sdm.de) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FGcab-0003Hf-EY; Tue, 07 Mar 2006 08:51:01 -0500 Original-Received: by world1.sdm.de (MTA) via esmtp from mucns1.muc.sdm.de ([193.102.180.22]) id 1FGcXs-0005SG-Vu; Tue, 07 Mar 2006 14:48:13 +0100 Original-Received: by mucns1.muc.sdm.de (MTA) via esmtp from localhost ([127.0.0.1] helo=sdmmail1.sdm.de) id 1FGcXs-0003Sn-U2; Tue, 07 Mar 2006 14:48:12 +0100 Original-Received: from mucmail1.sdm.de ([193.102.180.175]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 14:48:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECB Thread-Index: AcRp0Ay3ca24/BEXSUe0xvlWhEqUOXYHCfGg Original-To: X-OriginalArrivalTime: 07 Mar 2006 13:48:11.0996 (UTC) FILETIME=[C67FD9C0:01C641ED] 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:51322 Archived-At: Hello, Sorry for reactivating such an old thread but the latest cvs-Emacs pops = this up for me: I saw, that balance-window has been completely reimplemented on base of a new c-level-function `window-tree'...fine, but: Tools like ECB makes a lot of handstands to exclude some windows (the special ECB-windows which display stuff like dirs, files and file- contents from being deleted by command like delete-other-windows etc... Or in general: To exclude these special ECB-windos from being taken into account in general (e.g. also by count-windows, walk-windows in special situations). This is done by advices which are save and only active when ECB is = active... Richard, do you remember this thread - see below? We had discussed how to prevent some special windows from being deleted? Now i think we would need a more general mechanism which would also = prevent such windows from being included in the tree returned by `window-tree' = so all features based on new `window-tree' (AFAIK currently only = `balance-window') can ignore this window from their doing.... I think this is not necessary for the current Emacs-release but a least = then, when ECB should be integrated into Emacs (at least if this is intended ;-) But for now: Are there some work-arounds possible how to exclude some = windows from being "balanced" (means ajusted) by the new balance-window? In the old one an advice for `walk-windows' was enough which simply does = not walk through these special windows... But now, `walk-windows' is not = used but `window-tree'... Any suggestions? Thanks a lot in advance! Ciao, klaus Richard Stallman wrote: > >Do you think that this feature should be integrated into Emacs > at the >C level? >=20 > Hmm, depends. IMO Emacs is not really designed for having a > window-layout where some windows should be permanent and should > always contain some certain stuff (like the special > ECB-browsing-tree-buffers/windows) and the rest of the windows > which can be deleted and created by the user (like the > editing-area of ECB). >=20 > Not now; that's why I'm suggesting to change it. >=20 > BTW: If you remember we had already a short discussion about the > adding a mechanism (flag) to the c-level so a window can be marked > to be excluded from delete-other-window... please apologize but i > haven't still found enough time to implement this. >=20 > I remembered having that discussion, but not who I had discussed it > with. It sounds like ECB has implemented the same feature (more or=20 > less) at Lisp level. Do you agree that C level would be the best > place to put it?=20 >=20 >=20 > Example: ECB advices the `display-buffer' so it displays all > "compilation"-buffers (buffers which fulfill criterias a user has > defined so they should be displayed in the > compilation-output-window of ECB) in the > compilation-output-window of ECB (an optional but then permanent > window at the bottom of the ecb-frame), all special ecb-buffers > in the assigned ecb-window and for the rest of the buffers it > uses the edit-area of the ecb-frame as if this area would be the > whole frame. Works save and like a charm but needs for this a big > and - i admit - complex advice. So IMHO it would make sense for > some mechanisms (needed by ECB) to be included in the Emacs-core > because IMHO it is always better - regardless of the code-quality > and the saveness of an advive of an internal central function > like display-buffer - to implement this in the emacs-core instead > with an advice.=20 >=20 > That's exactly what I think. In fact, we want to avoid defining any > advice in Emacs itself.=20 >=20 > The question is if it should be at the c-level > or at the lisp-level? >=20 > It should be implemented within display-buffer, which means, in C > level.=20 >=20 > To rewrite display-buffer in Lisp is a separate idea. I'm not > against it, if someone wants to do it. Not right now; now our focus > is on getting a release to work. But if you want to do that, it > would be ok, and we could install that just before installing ECB. =20