ECB

ECB

[Dr. F.C.Caner]

Hello everyone,

I wonder if ECB supports any fortran extensions (f77/90/95/2000)?

Cheers,

FCC

Re: ECB

[Klaus Berndl]

On 23 Jan 2003, F. C. Caner wrote:



>  Hello everyone,
>  
>  I wonder if ECB supports any fortran extensions (f77/90/95/2000)?

Currently not, because there is no fortran semantic-parser available and ECB
is based completely on the parsing-capabilities of semantic, means ECB
supports always exactly these languages supported by semantic.

Write a a semantic bnf-file for fortran and ECB will support fortran... ;-)

But i think in the near future there will be released the first beta release
of semantic 2.0 and AFAIK semantic 2.0 supports more languages than current
version 1.4 but i do not know if fortran is included?

Ciao,
Klaus

-- 
Klaus Berndl			mailto: klaus.berndl@sdm.de
sd&m AG				http://www.sdm.de
software design & management	
Thomas-Dehler-Str. 27, 81737 München, Germany
Tel +49 89 63812-392, Fax -220

ECB

[Richard Stallman]

Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
and tell me what you think of it?

Re: ECB

[Jason Rumney]

Richard Stallman wrote:

>Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
>and tell me what you think of it?
>  
>
I use it every day, and I find it useful.

Its purpose is similar to speedbar, but it seperates Directories, Files 
and Tags into separate buffers, which many people find easier to work 
with. It also has some extra buffers that do not have an equivalent in 
speedbar, such as History and can also embed speedbar in one of its 
navigation windows if you prefer speedbar but want to use ECB for some 
reason.

The biggest difference between ECB and speedbar is that speedbar always 
appears in a seperate frame (it can be forced into another frame, but it 
is not easy), whereas ECB has several layout options, AFAIK all of which 
use windows within the current frame. Many people are used to working in 
other programs within the same frame, so they may see this as an 
improvement over speedbar.

Re: ECB

[Jérôme Marant]

Jason Rumney <jasonr@gnu.org> writes:


> The biggest difference between ECB and speedbar is that speedbar
> always appears in a seperate frame (it can be forced into another
> frame, but it is not easy), whereas ECB has several layout options,
> AFAIK all of which use windows within the current frame. Many people
> are used to working in other programs within the same frame, so they
> may see this as an improvement over speedbar.

IIRC, ECB uses tree-widget, which has recently been added to the Emacs
trunk. I think this is what you compare with speedbar.

Cheers,

-- 
Jérôme Marant

Re: ECB

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
> and tell me what you think of it?

One difference between an IDE and Emacs is that IDEs often show
various bits of information about the current project in little
windows around the suorce code.  With ECB, Emacs can do the same
thing.

ECB is très cool.

Note that ECB works with CEDET which provides parsing of source
code.  This is a framework that has lots of potential for vastly
improving Emacs' support for different programming languages.  What
we can see in ECB is merely the tip of the iceberg.  I think that
including CEDET in Emacs would enable various other packages to take
advantage of it.  For example, font-lock could be improved by better
parsing, as could syntactic indentation.  CEDET already provides
syntax-driven completion: if x is a struct, then completing after
"x." completes the members of that struct.

CEDET is très cool.

Kai

Re: ECB

[Stefan]

> CEDET is très cool.

Indeed.  But it needs to be made lazier and less global.
Last time I tried to use JDE (which uses CEDET) it ended up taking a very
significant time to open up an Elisp or a C file even though I only ever
used CEDET-related operations on Java files.


        Stefan

Re: ECB

[Richard Stallman]

Does speedbar have any advantages over ECB?  In other words, if
we replaced Speedbar with ECB, would we lose anything?
If so, could those features be added to ECB?

Having both ECB and Speedbar would be duplication, and in general
it is better to avoid duplication when there's no good reason for it.

Re: ECB

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> Does speedbar have any advantages over ECB?  In other words, if
> we replaced Speedbar with ECB, would we lose anything?
> If so, could those features be added to ECB?

It is a different interface which many longtime Emacs users may be
used to. I don't think ECB can display in a seperate frame, though it
might be easy to change it so. There may also be modes that speedbar
supports that ECB does not. Speedbar seems to have special support for
info for instance, which I don't think is present in ECB.

> Having both ECB and Speedbar would be duplication, and in general
> it is better to avoid duplication when there's no good reason for it.

We already have duplication between etags and imenu. And semantic
(part of CEDET, along with speedbar) offers more features over both.
ECB and speedbar are just different ways of presenting the
information etags, imenu and semantic can produce. Speedbar uses one
buffer in a seperate frame containing a single tree heirachy. ECB
uses several buffers for different types of information.

Re: ECB

[Richard Stallman]

    Note that ECB works with CEDET which provides parsing of source
    code.  This is a framework that has lots of potential for vastly
    improving Emacs' support for different programming languages.

Could you tell me more about CEDET?

      I think that
    including CEDET in Emacs would enable various other packages to take
    advantage of it.  For example, font-lock could be improved by better
    parsing, as could syntactic indentation.  CEDET already provides
    syntax-driven completion: if x is a struct, then completing after
    "x." completes the members of that struct.

What language is CEDET written in?  What is its license?  How would we
make Emacs talk with it?

This could be a big step forward IF there is no horrible snag.

Re: ECB

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

>     Note that ECB works with CEDET which provides parsing of source
>     code.  This is a framework that has lots of potential for vastly
>     improving Emacs' support for different programming languages.
>
> Could you tell me more about CEDET?

The home page is cedet.sourceforge.net.  The name stands for
Collection of Emacs Development Environment Tools.  The tool that I
alluded to in my previous message was Semantic.

Semantic is a lexer, a parser generator, and also a parser.  It also
contains some tools to make use of the parsing results.  For example,
Semantic integrates with imenu to provide a better menu.  I think it
also integrates with eldoc to show function prototypes (function
signatures) for more languages.  And I already mentioned the
syntax-driven completion module.  There is also a component for
navigating the source code.  This one can navigate the source
according to syntactic constructs of the language:
forward-identifier, forward-statement, forward-block,
forward-method/subroutine/function/defun, forward-class, ...  There
is also a generalization of backward-up-list which groks statements,
block, classes etc.

My understanding is that the parsers generated by Semantic are
incremental, which is what you need for editing.

In addition to Semantic, there is also EDE which manages projects.
My understanding is that it can parse an AutoMake file and thus knows
which target a certain source file belongs to, so that it can offer
the right make target for compilation.  I guess it can do more that
is not immediately apparent.  There is also another module which can
write Makefiles for you, it appears to be useful for small projects.
Then people don't need to learn make or Autoconf.

Then there is COGRE for drawing diagrams.  It can create UML diagrams
from source code and display them, IIUC.

And then, CEDET contains libraries and utilities that are used for
implementing the other packages.

I hope that I have not misrepresented the CEDET functionality too
much.

>     I think that including CEDET in Emacs would enable various other
>     packages to take advantage of it.  For example, font-lock could
>     be improved by better parsing, as could syntactic indentation.
>     CEDET already provides syntax-driven completion: if x is a
>     struct, then completing after "x." completes the members of that
>     struct.
>
> What language is CEDET written in?

Emacs Lisp.

> What is its license?

GPL.

> How would we make Emacs talk with it?

Like any other Lisp package ;-)

> This could be a big step forward IF there is no horrible snag.

I agree totally.

Kai

Re: ECB

[Jason Rumney]

Kai Grossjohann <kai@emptydomain.de> writes:

> And then, CEDET contains libraries and utilities that are used for
> implementing the other packages.
>
> I hope that I have not misrepresented the CEDET functionality too
> much.

speedbar is also a part of CEDET. My understanding is that these
tools originally started as seperate elisp libraries, but have grown
dependant on each other and the author (Eric Ludlam <zappo@gnu.org>)
has decided to release them as a single package in future.

Re: ECB

[Jens Lautenbacher]

[-- Attachment #1.1: Type: text/plain, Size: 1472 bytes --]

On Sun, 2004-07-04 at 04:13, Richard Stallman wrote:
>     Note that ECB works with CEDET which provides parsing of source
>     code.  This is a framework that has lots of potential for vastly
>     improving Emacs' support for different programming languages.
> 
> Could you tell me more about CEDET?

As far as I know CEDET is the "new" package that encompasses semantic,
speedbar, eieio and oher stuff. Previously these have been separate
packages, of which only speedbar has been included into emacs
distribution (?).  

> This could be a big step forward IF there is no horrible snag.

Indeed. CEDET, together with ECB that uses the facilities of CEDET
provides most of what's needed for a IDE. The nice thing about it that
the ECB features automatically work for EVERY language that has a CEDET
parser. Other, language specific stuff is provided by other languages. I
think the most advanced example is Java, where ECB/CEDET provide the
window layout with source code browsing features, and the special Java
relates stuff is provided by JDE. This includes stuff like running a
Java interpreter in the background to automatically query all classes on
the classpath for their accessible methods etc. which allows for
completion not only in the current soure buffer (or a buffer already
parsed by CEDET) but on every callable class even if you only have it
packed in a .jar file.

In other words: ECB/CEDET together with JDE rocks.

	jtl

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: ECB

[Eric M. Ludlam]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 3195 bytes --]

Hi,

  I get emacs-devel as a digest.  Here is a reply to a few messages
  on the list.

>>> Kai Grossjohann <kai@emptydomain.de> wrote:
>> Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
>> and tell me what you think of it?
>
>One difference between an IDE and Emacs is that IDEs often show
>various bits of information about the current project in little
>windows around the suorce code.  With ECB, Emacs can do the same
>thing.
>
>ECB is très cool.
>
>Note that ECB works with CEDET which provides parsing of source
>code.  This is a framework that has lots of potential for vastly
>improving Emacs' support for different programming languages.  What
>we can see in ECB is merely the tip of the iceberg.  I think that
>including CEDET in Emacs would enable various other packages to take
>advantage of it.  For example, font-lock could be improved by better
>parsing, as could syntactic indentation.  CEDET already provides
>syntax-driven completion: if x is a struct, then completing after
>"x." completes the members of that struct.
>
>CEDET is très cool.

Just as an FYI on CEDET, all of the individual tools in it have
already had papers signed for them and sent in.  I have to get
periodic papers from my employer and a set is currently wandering
through the legal department.

>>> Stefan <monnier@iro.umontreal.ca> wrote:
>> CEDET is très cool.
>
>Indeed.  But it needs to be made lazier and less global.
>Last time I tried to use JDE (which uses CEDET) it ended up taking a very
>significant time to open up an Elisp or a C file even though I only ever
>used CEDET-related operations on Java files.

I recall your email to me.  The current CVS version has since been
updated to delay parsing to an idle timer.  Tools that need the
buffer parsed now must wait until an idle timer goes off, so related
decorations don't show up till a few seconds after the buffer is
visible.  Your other request of disabling parsing for an individual
mode is still on my to-do list but it is unclear to me what to do
about it since all the load-time hooks are auto-generated in
auto-load files.

>>> From: Jason Rumney <jasonr@gnu.org>
>Kai Grossjohann <kai@emptydomain.de> writes:
>
>> And then, CEDET contains libraries and utilities that are used for
>> implementing the other packages.
>>
>> I hope that I have not misrepresented the CEDET functionality too
>> much.
>
>speedbar is also a part of CEDET. My understanding is that these
>tools originally started as seperate elisp libraries, but have grown
>dependant on each other and the author (Eric Ludlam <zappo@gnu.org>)
>has decided to release them as a single package in future.

This is indeed correct.  Releasing one tool often required a new
release of another with only one bug fix in it.  It was quite a
hassle.  Releasing them all at once has simplified things, but made
testing a bit more challenging.

Enjoy
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: ECB

[Stefan]

> I recall your email to me.  The current CVS version has since been
> updated to delay parsing to an idle timer.  Tools that need the
> buffer parsed now must wait until an idle timer goes off, so related
> decorations don't show up till a few seconds after the buffer is
> visible.

Great to hear.

> Your other request of disabling parsing for an individual
> mode is still on my to-do list but it is unclear to me what to do
> about it since all the load-time hooks are auto-generated in
> auto-load files.

I'm not sure whether it should be on the todo list.  I think I mentioned it
more as a "this is so slow, please do *something*".  Other approaches such
as laziness are much better.

But if it's still deemed necessary, a way to "enable for a few specific
modes" would be more useful to me than a way to "disable for a few specific
modes".


        Stefan

Re: ECB

[Richard Stallman]

    We already have duplication between etags and imenu.

I hope you are not arguing that the presence of some of this flaw in
Emacs now means we should not try to avoid adding more.  I disagree
completely.  To have one flaw is not a good reason to add another.  To
the extent there is duplication between etags and imenu, that is
unfortunate.  More duplication would be more unfortunate.

    It is a different interface which many longtime Emacs users may be
    used to. I don't think ECB can display in a seperate frame, though it
    might be easy to change it so. There may also be modes that speedbar
    supports that ECB does not. Speedbar seems to have special support for
    info for instance, which I don't think is present in ECB.

Assuming ECB is well written and that it can be integrated well with
Emacs, we have a choice between installing ECB along with Speedbar, or
improving ECB to do all the things that Speedbar does, and replacing
Speedbar.  Making ECB subsume Speedbar would produce a simpler editor
that is easier to maintain, so that's the option we should aim for.

Would someone like to determine precisely which features we would
need to add to ECB to make this possible?

Meanwhile, another question is what needs to be done to integrate
ECB into Emacs cleanly.  Could someone take a look at that?

Neither of these questions is a rush.  We won't be doing any of this
before the next release.

Re: ECB

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Assuming ECB is well written and that it can be integrated well with
> Emacs, we have a choice between installing ECB along with Speedbar, or
> improving ECB to do all the things that Speedbar does, and replacing
> Speedbar.  Making ECB subsume Speedbar would produce a simpler editor
> that is easier to maintain, so that's the option we should aim for.

I thought (from other posts) that ECB essentially _contained_ speedbar,
though probably an updated version -- so it seems like there would be
little pain in moving to ECB from that perspective.

-Miles
-- 
I'd rather be consing.

Re: ECB

[Jason Rumney]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I thought (from other posts) that ECB essentially _contained_ speedbar,
> though probably an updated version -- so it seems like there would be
> little pain in moving to ECB from that perspective.

It can contain (physically on the screen, not as part of the Lisp
package) speedbar, but that is an option. It also uses speedbar
functionality to support modes that are not supported by semantic.

Re: ECB

[Richard Stallman]

    > I thought (from other posts) that ECB essentially _contained_ speedbar,
    > though probably an updated version -- so it seems like there would be
    > little pain in moving to ECB from that perspective.

    It can contain (physically on the screen, not as part of the Lisp
    package) speedbar, but that is an option. It also uses speedbar
    functionality to support modes that are not supported by semantic.

So, does this mean that ECB makes the existing Speebar package
obsolete?

If not, then why not?

Re: ECB

[Berndl, Klaus]

 
Richard Stallman <address@bogus.example.com> writes:
>> Assuming ECB is well written and that it can be integrated well with
>> Emacs, we have a choice between installing ECB along with Speedbar, or
>> improving ECB to do all the things that Speedbar does, and replacing
>> Speedbar.  Making ECB subsume Speedbar would produce a simpler editor
>> that is easier to maintain, so that's the option we should aim for.

>I thought (from other posts) that ECB essentially _contained_ speedbar,
>though probably an updated version -- so it seems like there would be
>little pain in moving to ECB from that perspective.

No, this isn't true. ECB can display speedbar in one of its special
buffers/windows but this is more like an additional feature for people
who like speedbar but do not like the extra-frame of speedbar.

Klaus

Klaus Berndl                     mailto: klaus.berndl@sdm.de
sd&m AG                         http://www.sdm.de
software design & management
Carl-Wery-Str. 42, 81739 Muenchen, Germany
Tel +49 89 63812-392, Fax -220

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

RE: ECB

[Berndl, Klaus]

Berndl, Klaus wrote:
>>> The biggest difference between ECB and speedbar is that speedbar
>>> always appears in a seperate frame (it can be forced into another
>>> frame, but it is not easy), whereas ECB has several layout options,
>>> AFAIK all of which use windows within the current frame. Many people
>>> are used to working in other programs within the same frame, so they
>>> may see this as an improvement over speedbar.
> 
>> IIRC, ECB uses tree-widget, which has recently been added to the
>> Emacs trunk. I think this is what you compare with speedbar.
> 
> No, ECB doesn't use the tree-widget lib it uses its own tree-library!
> 
> Klaus
> 
> Klaus Berndl                     mailto: klaus.berndl@sdm.de
> sd&m AG                         http://www.sdm.de
> software design & management
> Carl-Wery-Str. 42, 81739 Muenchen, Germany
> Tel +49 89 63812-392, Fax -220

Re: ECB

[Jérôme Marant]

"Berndl, Klaus" <klaus.berndl@sdm.de> writes:

> Berndl, Klaus wrote:
>>>> The biggest difference between ECB and speedbar is that speedbar
>>>> always appears in a seperate frame (it can be forced into another
>>>> frame, but it is not easy), whereas ECB has several layout options,
>>>> AFAIK all of which use windows within the current frame. Many people
>>>> are used to working in other programs within the same frame, so they
>>>> may see this as an improvement over speedbar.
>> 
>>> IIRC, ECB uses tree-widget, which has recently been added to the
>>> Emacs trunk. I think this is what you compare with speedbar.
>> 
>> No, ECB doesn't use the tree-widget lib it uses its own tree-library!

My apologies. While unpacking ecb, I was confused with tree-buffer.el
which my mind turned into tree-widget.el :-)

Cheers,

-- 
Jérôme Marant

Re: ECB

[Richard Stallman]

    But IMO it would make sense to offer both ECB and speedbar so a user can
    deside for himself which interface he likes more...

Could ECB implement both interfaces, so that the user use ECB
and still decide for himself which interface he likes more?

Re: ECB

[Richard Stallman]

    But IMO it would make sense to offer both ECB and speedbar so a user can
    deside for himself which interface he likes more...

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.

    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?

    - Required packages: either CEDET or the standalone libs eieio, semantic and
      speedbar (the need of the latter one is discussed above)

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?

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.

    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.

I think we do want to integrate it.  This may need multiple steps.

Can you tell me how many lines of code are in ECB, in eieio, and in semantic?

Re: ECB

[Richard Stallman]

Could you tell us more about semantic?

For instance, is it written entirely in Emacs Lisp?
If not, what other languages are needed?  Does it use any
separate auxiliary programs?

Are you the author of semantic?
If not, could you tell me how to reach the author?
It seems very desirable to include semantic in Emacs.

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

Re: ECB

[Richard Stallman]

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

Not now; that's why I'm suggesting to change it.

    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.

I remembered having that discussion, but not who I had discussed it
with.  It sounds like ECB has implemented the same feature (more or
less) at Lisp level.  Do you agree that C level would be the best
place to put it?


    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.

That's exactly what I think.  In fact, we want to avoid defining any
advice in Emacs itself.

			The question is if it should be at the c-level
			or at the lisp-level?

It should be implemented within display-buffer, which means, in C
level.

To rewrite display-buffer in Lisp is a separate idea.  I'm not against
it, if someone wants to do it.  Not right now; now our focus is on getting
a release to work.  But if you want to do that, it would be ok, and
we could install that just before installing ECB.

Re: ECB

[Richard Stallman]

    First of all we would have to specify what it is that "speedbar-like"-behavior.

I would define it as "whatever behavior Speedbar offers
that users would miss if they had to switch to ECB."
										    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)

In principle, any and all of these that a substantial number of users
like.  Perhaps users don't really like #1; they might generally prefer
the ECB approach.  I don't know whether users like #2, but I suspect
some do.  #3 and #4 are features, so I'm sure users like them.

RE: ECB

[klaus.berndl]

Hello,

Sorry for reactivating such an old thread but the latest cvs-Emacs pops this
up for me:

I saw, that balance-window has been completely reimplemented on base of
a new c-level-function `window-tree'...fine, but:

Tools like ECB makes a lot of handstands to exclude some windows (the
special ECB-windows which display stuff like dirs, files and file-
contents from being deleted by command like delete-other-windows etc...
Or in general: To exclude these special ECB-windos from being taken into
account in general (e.g. also by count-windows, walk-windows in special
situations).

This is done by advices which are save and only active when ECB is active...

Richard, do you remember this thread - see below?
We had discussed how to prevent some special windows from being deleted?
Now i think we would need a more general mechanism which would also prevent
such windows from being included in the tree returned by `window-tree' so
all features based on new `window-tree' (AFAIK currently only `balance-window')
can ignore this window from their doing....

I think this is not necessary for the current Emacs-release but a least then, when
ECB should be integrated into Emacs (at least if this is intended ;-)

But for now: Are there some work-arounds possible how to exclude some windows
from being "balanced" (means ajusted) by the new balance-window?
In the old one an advice for `walk-windows' was enough which simply does not
walk through these special windows... But now, `walk-windows' is not used but
`window-tree'...

Any suggestions?

Thanks a lot in advance!

Ciao,
klaus

Richard Stallman wrote:
>     >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).
> 
> Not now; that's why I'm suggesting to change it.
> 
>     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.
> 
> I remembered having that discussion, but not who I had discussed it
> with.  It sounds like ECB has implemented the same feature (more or 
> less) at Lisp level.  Do you agree that C level would be the best
> place to put it? 
> 
> 
>     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. 
> 
> That's exactly what I think.  In fact, we want to avoid defining any
> advice in Emacs itself. 
> 
> 			The question is if it should be at the c-level
> 			or at the lisp-level?
> 
> It should be implemented within display-buffer, which means, in C
> level. 
> 
> To rewrite display-buffer in Lisp is a separate idea.  I'm not
> against it, if someone wants to do it.  Not right now; now our focus
> is on getting a release to work.  But if you want to do that, it
> would be ok, and we could install that just before installing ECB.   

Re: ECB

[Stefan Monnier]

> But for now: Are there some work-arounds possible how to exclude some
> windows from being "balanced" (means ajusted) by the new balance-window?
> In the old one an advice for `walk-windows' was enough which simply does
> not walk through these special windows... But now, `walk-windows' is not
> used but `window-tree'...

balance-windows should obey `window-size-fixed'.  I don't know whether it
does, and neither do I know whether ECB can use it.


        Stefan

RE: ECB

[klaus.berndl]

Stefan Monnier wrote:
>> But for now: Are there some work-arounds possible how to exclude some
>> windows from being "balanced" (means ajusted) by the new
>> balance-window? In the old one an advice for `walk-windows' was
>> enough which simply does not walk through these special windows...
>> But now, `walk-windows' is not used but `window-tree'...
> 
> balance-windows should obey `window-size-fixed'.  I don't know
> whether it does, and neither do I know whether ECB can use it. 

Ah, very interesting - supposed balance-windos obeys window-sized-fixed
then ECB could advice `balance-window' and setting window-sized-fix to t temporally
for the buffers displayed by the special ECB-windows (which should be ignored for
balancing)...

Is not a generall solution for such problems (i mentioned in my posting) but sounds
like a promising workaround for making newest balance-windows compatible with ECB...

Thanks!

Ciao,
Klaus

> 
> 
>         Stefan

Re: ECB

[Richard Stallman]

    Now i think we would need a more general mechanism which would also prevent
    such windows from being included in the tree returned by `window-tree' so
    all features based on new `window-tree' (AFAIK currently only `balance-window')
    can ignore this window from their doing....

Would you like to implement these features, for future installation?

Re: ECB

[Richard Stallman]

    Ah, very interesting - supposed balance-windos obeys window-sized-fixed
    then ECB could advice `balance-window' and setting window-sized-fix to t temporally
    for the buffers displayed by the special ECB-windows (which should be ignored for
    balancing)...

It should not use advice!

Why not set window-size-fixed permanently in these buffers?

RE: ECB

[klaus.berndl]

Richard Stallman wrote:
>     Ah, very interesting - supposed balance-windos obeys
>     window-sized-fixed then ECB could advice `balance-window' and
>     setting window-sized-fix to t temporally for the buffers
>     displayed by the special ECB-windows (which should be ignored for
> balancing)... 
> 
> It should not use advice!
> 
> Why not set window-size-fixed permanently in these buffers?

IMHO this should be the users choice if he/she wants to side-panel
(or top-panal for layouts of type top) of the ECB-windows being fixed
when resizing the ECB-frame.

In general i agree with you concerning using advices, but IMO currently
they are still necessary if one wants to build something like ECB on top
of Emacs and give the users the feeling if the edit-windows of ECB are 
the only windows in the frame and allow all features users are used to 
use (e.g. deciding if they want windows fixed or not...)

Until we have a robust and general mechanism to exclude special windows
from being taken into account by fnctions like deleting, balancing windows
etc.... (as i described in my previous posting) ECB will use advices as
best possible workaround. The advices of ECB are always safe because they
are savely only active when ECB is active...

RE: ECB

[klaus.berndl]

Richard Stallman wrote:
>     Now i think we would need a more general mechanism which would
>     also prevent such windows from being included in the tree
>     returned by `window-tree' so all features based on new
>     `window-tree' (AFAIK currently only `balance-window') can ignore
> this window from their doing.... 
> 
> Would you like to implement these features, for future installation?

If on c-level then i doubt that i have enough know-how of the c-code of Emacs
to implement a good solution... IMVHO the best would be to check in `display-buffer'
(and also in routines like `window-tree'?!) If a window should be excluded from some
actions... And IMVHO display-buffer should be moved from c-kernel to elisp-code
(as already done by XEmacs ;-)

If we can implement the new feature on elisp-level i would be willing to imlement
it - at least i would try it ;-)

Ciao,
klaus

Re: ECB

[Stefan Monnier]

> And IMVHO display-buffer should be moved from c-kernel to elisp-code

100% agreement.


        Stefan

RE: ECB

[Drew Adams]

    > And IMVHO display-buffer should be moved from c-kernel to elisp-code
    
    100% agreement.
    
Me too.

Re: ECB

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 08 Mar 2006 09:54:33 -0500
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> > And IMVHO display-buffer should be moved from c-kernel to elisp-code
> 
> 100% agreement.

Based on what, exactly?  Do we know for a fact that its performance is
so unimportant that the slower running times of Lisp will go
unnoticed?

Re: ECB

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>     > And IMVHO display-buffer should be moved from c-kernel to elisp-code
>
>     100% agreement.
>
> Me too.

In general it's nice ... but to enable the use of "defadvice" isn't
exactly the best motivation!

-miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: ECB

[Stefan Monnier]

>> > And IMVHO display-buffer should be moved from c-kernel to elisp-code
>> 100% agreement.
> Based on what, exactly?  Do we know for a fact that its performance is
> so unimportant that the slower running times of Lisp will go
> unnoticed?

I must say I'd be stunned if you could show me any evidence that an elisp
implementation would incur any noticeable preformance hit: if you look at
the C code of display-buffer you'll see it has no loop, and if you look at
the calls to display-buffer you'll see it's never called inside a loop.
I.e. its performance is completely uninteresting.


        Stefan

Re: ECB

[Richard Stallman]

    Until we have a robust and general mechanism to exclude special windows
    from being taken into account by fnctions like deleting, balancing windows
    etc.... (as i described in my previous posting) ECB will use advices as
    best possible workaround.

Please don't implement this through advice!  Implement this through
extending the primitives to do what you need!

Re: ECB

[Eli Zaretskii]

> Cc: klaus.berndl@sdm.de,  rms@gnu.org,  emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 09 Mar 2006 11:04:23 -0500
> 
> I must say I'd be stunned if you could show me any evidence that an elisp
> implementation would incur any noticeable preformance hit

I don't need to show any evidence because I'm not arguing for any
change.

Re: ECB

[Juri Linkov]

>> And IMVHO display-buffer should be moved from c-kernel to elisp-code
>
> 100% agreement.

Rewriting display-buffer in C will also help implement a new option for
a persistent horizontal split:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2005-12/msg00267.html

-- 
Juri Linkov
http://www.jurta.org/emacs/