RE: ECB

[Berndl, Klaus]

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