From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Berndl, Klaus" Newsgroups: gmane.emacs.devel Subject: RE: ECB Date: Tue, 13 Jul 2004 14:42:31 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1B3ACCFD5694A94DBA4E231402B0E9ED040976@mucmail1.sdm.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Trace: sea.gmane.org 1089722594 10536 80.91.224.253 (13 Jul 2004 12:43:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2004 12:43:14 +0000 (UTC) Cc: "'emacs-devel@gnu.org '" Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jul 13 14:43:03 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 1BkMch-0001rX-00 for ; Tue, 13 Jul 2004 14:43:03 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BkMcg-00031l-00 for ; Tue, 13 Jul 2004 14:43:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BkMf3-0004wB-Bn for emacs-devel@quimby.gnus.org; Tue, 13 Jul 2004 08:45:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BkMes-0004w6-Sz for emacs-devel@gnu.org; Tue, 13 Jul 2004 08:45:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BkMer-0004vu-Os for emacs-devel@gnu.org; Tue, 13 Jul 2004 08:45:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BkMer-0004vr-Ga for emacs-devel@gnu.org; Tue, 13 Jul 2004 08:45:17 -0400 Original-Received: from [192.76.162.229] (helo=world1.sdm.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BkMcO-0003M4-Nr; Tue, 13 Jul 2004 08:42:45 -0400 Original-Received: from localhost ([127.0.0.1] helo=world1.sdm.de) by world1.sdm.de (MTA) via esmtp id 1BkMcN-0007o2-4m; Tue, 13 Jul 2004 14:42:43 +0200 Original-Received: from mucns1.muc.sdm.de ([193.102.180.22]) by world1.sdm.de (MTA) via esmtp id 1BkMcE-0007nK-NN; Tue, 13 Jul 2004 14:42:34 +0200 Original-Received: by mucns1.muc.sdm.de (MTA) via esmtp from localhost ([127.0.0.1] helo=sdmexch1.muc.sdm.de) id 1BkMcE-00016C-Ki; Tue, 13 Jul 2004 14:42:34 +0200 Original-Received: by sdmexch1.muc.sdm.de with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jul 2004 14:42:34 +0200 Original-To: 'Richard Stallman ' X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message x-mimeole: urn:content-classes:message x-sdm-mailscanner-spamcheck: urn:content-classes:message x-sdm-mailscanner-envelope-from: urn:content-classes:message 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:25645 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25645 >I agree it would be good to offer the user both interfaces. >One way to do that is by having both ECB and Speedbar in Emacs. >But that is not the clean way to do it. >Could you implement speedbar-like behavior as an option in ECB? If >that is easy to do, it would be a big simplification. We would not >have to maintain both (all of) Speedbar and ECB. The parts of >Speedbar that ECB needs, we could integrate into ECB. First of all we would have to specify what it is that "speedbar-like"-behavior. Is it: 1. The combination of directory- and file-content-browsing within one window (ECB separates the directory- and file-browser and the contents-browser in different windows whereas speedbar displays all stuff in one big tree 2. Displaying all stuff in an extra frame 3. Offering all the special-modes of speedbar, e.g. "buffers"-mode, "info"-mode etc... 4. Supporting all packages which currently use the speedbar-API to display special views for certain code-types (e.g. vhdl-mode.el) Point 1 would be hard to implement but IMHO i would always prefer different windows for different content so i would plead for not porting this speedbar behavior to ECB. But maybe this is a matter of taste (a pro argument for offering speedbar also in the future?!) Point 2 could probably be implemented in ECB but would need some significant work. Point 3 is probably quite easy to introduce into ECB Point 4 would be possible too. But this would need some additional work for the ECB-API (but this is not hard and also not many effort) and - which is a lot of more effort - this would mean that every package which currently uses the speedbar-API for special displays has to be ported to the ECB-API to display its own stuff - see the speedbar-homepage for a list of elisp-packages which currently use the speedbar-API for that. IMHO another pro argument for supporting both speedbar and ECB in the future. >> ECB has currently a quite powerful layout-engine which allows an >> user to create its own window-layout interactively and on the other >> hand offers a programming-API to program/create completely new >> special windows (to display whatever you want) and synchronize it >> with the editing-area of ECB. >That sounds quite interesting. >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). For example one problem is, that currently Emacs has the dedicated-window concept but has no mechanism to prevent that commands like delete-other-window exclude some windows from this deletion. So ECB makes really some hard handstands ;-) to achieve this goal. This results in sophisticated advices of functions like split-window, delete-window. delete-other-windows, display-buffer (one of the most important adviced, because ECB needs full controll where to display certain buffers!) 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. All the advices of ECB are completely save, ie. behave only special in the ecb-frame (in all other frames they behave like the original), are only activated if ECB is activated (==> all advices will be first activated when ECB is activated and will be deactivated when ECB will be deactivated!) and so on: 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 f or 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. The question is if it should be at the c-level or at the lisp-level? For example the XEmacs-crew has implemented the full display-buffer function in emacs-lisp which has IMHO some advantages over the c-level version of GNU Emacs... Summary: ECB needs some special and new window-mechanism (mainly in the context, how to exclude certain windows to be deleted by delete-other-window, how to prevent certain windows from being splitted and how to ensure that a certain buffer will be always displayed in a certain window of a frame (but not in the meaning of the same window-object but more in the meaning of the same logical window of a frame, because switching to another window-layout of ECB (ECB offers a lot of prebuzild layouts and the user can create own layouts) would destroy all existing window-objects and create completely new window-objects buf the buffers should still being displayed in the same logical windows - sorry, but i can not describe it better at the moment) See the ECB-info-manual to get a list which functions are adviced by ECB! >Is it accurate to describe CEDET as a packaging of eieio, semantic, >and speedbar? If not, could you clear up my misunderstanding? >Does CEDET contain other things aside from eieio, semantic, and >speedbar? generally speaking you understand it right. It contains in addition some utility sublibs like a progress-bar, a mode-local lib etc... but i think Eric has already answered this in more detail in another posting?! >If we want to put eieio and semantic into Emacs, I think we would be >better off without having them packaged in the form of CEDET. Emacs >has its own system of makefiles, and to get clean results, we would >want to handle eieio and semantic like all the rest of the Lisp code >in Emacs. Of course but for this i think we should integrate Eric Ludlum because he can give the best answeres to this problems. >Can you tell me how many lines of code are in ECB, in eieio, and in >semantic? Can only speak for ECB (for the cedet-libs ERic can give the answers) All lines in the *.el-files of ECB (wc -l *.el): ~ 26000 All lines without empty lines: ~ 23000 All lines without empty lines and without pure comment-lines: ~ 20000 /Klaus