From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: ECB Date: Wed, 14 Jul 2004 14:26:08 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <1B3ACCFD5694A94DBA4E231402B0E9ED040976@mucmail1.sdm.de> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1089829602 28638 80.91.224.253 (14 Jul 2004 18:26:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Jul 2004 18:26:42 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jul 14 20:26:32 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BkoSe-0003kb-00 for ; Wed, 14 Jul 2004 20:26:32 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BkoSd-0002KO-00 for ; Wed, 14 Jul 2004 20:26:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BkoV4-0006Mm-LU for emacs-devel@quimby.gnus.org; Wed, 14 Jul 2004 14:29:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BkoUz-0006MZ-FP for emacs-devel@gnu.org; Wed, 14 Jul 2004 14:28:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BkoUy-0006MF-O9 for emacs-devel@gnu.org; Wed, 14 Jul 2004 14:28:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BkoUy-0006Lu-FS for emacs-devel@gnu.org; Wed, 14 Jul 2004 14:28:56 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BkoSG-0001Dy-PX for emacs-devel@gnu.org; Wed, 14 Jul 2004 14:26:08 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BkoSG-0003pC-CR; Wed, 14 Jul 2004 14:26:08 -0400 Original-To: "Berndl, Klaus" In-reply-to: <1B3ACCFD5694A94DBA4E231402B0E9ED040976@mucmail1.sdm.de> (klaus.berndl@sdm.de) 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: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25688 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25688 >Do you think that this feature should be integrated into Emacs at the >C level? 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). Not now; that's why I'm suggesting to change it. 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. I remembered having that discussion, but not who I had discussed it with. It sounds like ECB has implemented the same feature (more or less) at Lisp level. Do you agree that C level would be the best place to put it? 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. That's exactly what I think. In fact, we want to avoid defining any advice in Emacs itself. The question is if it should be at the c-level or at the lisp-level? It should be implemented within display-buffer, which means, in C level. 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.