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: Wed, 7 Jul 2004 18:54:19 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: sea.gmane.org 1089219300 26828 80.91.224.253 (7 Jul 2004 16:55:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 7 Jul 2004 16:55:00 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jul 07 18:54:48 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 1BiFh1-0002OJ-00 for ; Wed, 07 Jul 2004 18:54:47 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BiFh1-000502-00 for ; Wed, 07 Jul 2004 18:54:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BiFj5-0007oh-Re for emacs-devel@quimby.gnus.org; Wed, 07 Jul 2004 12:56:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BiFiy-0007oN-5I for emacs-devel@gnu.org; Wed, 07 Jul 2004 12:56:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BiFix-0007oB-KP for emacs-devel@gnu.org; Wed, 07 Jul 2004 12:56:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BiFix-0007o8-H9 for emacs-devel@gnu.org; Wed, 07 Jul 2004 12:56:47 -0400 Original-Received: from [192.76.162.229] (helo=world1.sdm.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BiFgg-0001ph-V6 for emacs-devel@gnu.org; Wed, 07 Jul 2004 12:54:27 -0400 Original-Received: from localhost ([127.0.0.1] helo=world1.sdm.de) by world1.sdm.de (MTA) via esmtp for id 1BiFgg-00077Z-GO; Wed, 07 Jul 2004 18:54:26 +0200 Original-Received: from mucns1.muc.sdm.de ([193.102.180.22]) by world1.sdm.de (MTA) via esmtp for id 1BiFge-00077J-0c; Wed, 07 Jul 2004 18:54:24 +0200 Original-Received: by mucns1.muc.sdm.de (MTA) via esmtp for from localhost ([127.0.0.1] helo=sdmexch1.muc.sdm.de) id 1BiFgd-0007dz-V3; Wed, 07 Jul 2004 18:54:23 +0200 Original-Received: by sdmexch1.muc.sdm.de with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jul 2004 18:54:23 +0200 Original-To: "'emacs-devel@gnu.org'" X-Mailer: Internet Mail Service (5.5.2653.19) 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:25529 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25529 Sorry for my late interaction but i have just subscribed to this list... But as the maintainer of ECB and currently the main-developer i think i should write down some aspects and answers to the previous postings: 1. Coexistence of speedbar and ECB and current dependencies Currently ECB uses some speedbar-code to display the contents of files which are currently not supported by the semantic-package (either the standalone semantic 1.4.X or the cedet-version of semantic which is shipped with the CEDET-suite. For such files (perl, html and others for which no semantic-parser currently exists) ECB merely uses the interface the speedbar package offers over the etags- and imenu-parsing-engines - so ECB has no need to deal with etags or imenu itself but can use this speedbar-interface. But this code could probably quite easy fully integrated into ECB itself so the dependency to speedbar could go away - but needs some extra programming in ECB. In general some people have already described the situation very well: ECB is another interface to display the contents of directories and of the source-files itself. Concerning displaying file-contents IMHO ECB is better and more powerful than speedbar, concering browsing directories it is probably a matter of taste... In general the look&feel of ECB is more like currently offered IDEs as Visual Studio etc... and therefore it might be more intuitive to use for many people - especially for Emacs-Newbies - also because it displays all its information windows (directories, files, file-contents etc.) in one frame one can be faster switch between its code-editing-aplication (Emacs) and other applications. On the other side speedbar has some more mode beside directory- and file-browsing, so e.g. a quity nifty buffer-browser and some more. Maybe Eric Ludlum can give us more advantages of speedbar over ECB ;-) But IMO it would make sense to offer both ECB and speedbar so a user can deside for himself which interface he likes more... 2. Flexibility for integration of other elisp-applications 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. 3. Which features are needed in ECB to subsume speedbar? Most things speedbar can do ECB can already do too. I can not judge the demand people have for the buffer-mode of speedbar or the info-mode. As said under 2. ECB offers already a powerful API to create new special windows which can display what you want and also a powerful tree-buffer library so all these speedbar-modes could in general be reimplemented in ECB. 4. What to do for integrating ECB cleanly into Emacs AFAICS this should be quite simple: - Required packages: either CEDET or the standalone libs eieio, semantic and speedbar (the need of the latter one is discussed above) - Internal structure of ECB: All lisp-files reside in one plain directory, the needed image-files for the icopn-displays of the tree-buffers reside currently in a deeply nested subdir ecb-images (this could be moved to etc of the Emacs dir-structure e.g.), ECB offers its help in info- and html- format ehich reside each in an own subdir info-help and html-help. I assume integrating ECB into Emacs would need a changed structure of ECB and for this some small code-changes would be necessary (so ECB can find its files) but all are quite simple. Conclusion: If the Emacs-team wants to integrate ECB into Emacs i would be glad to hear this and it goes withourt saying that i will help and support as well as possible. Klaus