RE: ECB

From:

Berndl, Klaus

Subject:

RE: ECB

Date:

Tue, 13 Jul 2004 14:42:31 +0200

>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