RE: ECB

["Berndl, Klaus" <klaus.berndl@sdm.de>]

>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