RE: ECB

[Berndl, Klaus]

>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 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. 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